Cannot create root-level Page instance when having deleted the default root-level Page

Cross-posted from Reddit: https://www.reddit.com/r/django/comments/i3amz3/root_page_and_wagtail_cms/
When working with a fresh Wagtail instance, it is possible for the content editor to delete the site root page (the default Wagtail Page instance).

Deleting the site root page will automatically delete the default site as well.

With both the initial root Page and Site deleted, the user cannot initialize a new Page hierarchy or create a new site.

I believe this is a usability bug because it leaves the user with a broken site. There would ideally be a way to recover from this "rootless" state through the Wagtail Admin UI.
Steps to Reproduce

Start a new project with wagtail start myproject
Log in with superuser
Delete the welcome page

I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: yes

Technical details

Python version: 3.8.3
Django version: 3.0.9
Wagtail version: 2.9.3
Browser version: Firefox 79.0

Hi @brylie,

There would ideally be a way to recover from this "rootless" state through the Wagtail Admin UI.

There is a way: create a page, and then create a site record pointing to it. The purpose of a site record is to define which page should be served up for a given hostname, so it's not meaningful to create a site record while no pages exist. How else would you see this working?

@gasman the OP mentions they are not able to create a new Page instance. I have verified there is no way to create a new Page instance in a rootless Wagtail. Ideally, the user could recover from this state by Wagtail allowing them to create a new Root Page.

A couple of strategies for handling this type of situation might be recovery or prevention.
Recovery
When Wagtail renders the pages list with a count of zero page instances, it could allow the user to create a new basic Page instance.
Prevention
Conversely, Wagtail could prevent the user from getting into this situation by not allowing the initial Page instance to be deleted without at least one other Page, or inherited model, instance available.

There is a way: create a page, and then create a site record pointing to it.

That was my initial advice. However, there doesn't seem to be a way to create a new Page instance via the UI.

This is what I see as a superuser when I delete the initial homepage, on a site that has just been created with wagtail start with no code changes:

So, I do still get the option for creating a new page. Is that not the case for you? (I can see there would be issues if you were logged in as an ordinary editor, or deleted the HomePage model, but that doesn't seem to be what's being described here.)

OK, I will update the steps-to-reproduce to mention that Wagtail is being integrated into an existing Django site.

Ah - I see that the original poster on Reddit is following the "Integration with Django" steps, so their codebase won't have the HomePage model defined. As a result, there are no page types available to create. Once they've installed Wagtail into their project, they need to continue following the main tutorial from here: https://docs.wagtail.io/en/v2.9.3/getting_started/tutorial.html#extend-the-homepage-model

This happened to me.   Probably because I didn't finish the last paragraph "Start Developing"
https://docs.wagtail.io/en/v2.14.1/getting_started/integrating_into_django.html#start-developing
I opened the site up, deleted the default home page.  I couldn't create a new site and I didn't see any new page types and didn't understand that I needed to create those.  I was unsure if Wagtail would generate them itself.  I reloaded a database backup, re-did the migrations and started over by creating a new app, a page model  and a template.

I'm bumping into this issue again, this time while writing unit tests that need to set up and tear down a Wagtail site structure in order to test various sections of our website. It would be really helpful if the Wagtail documentation had sections on testing and content migration since these are common concerns. While many aspects of testing and content migration are indeed unique to each project there are still some general patterns that could be added to the Wagtail documentation.

Hi @brylie - as far as I can see, this issue is about a usability gotcha that arises when integrating Wagtail into an existing site, and deleting the initial homepage without having first defined any page models of your own. I can't see how that relates to unit testing - please can you open a new issue expanding on what you feel is missing from the documentation?

It maybe sounds stupid, but I also faced this problem of not being able to add new (child) pages. But I wasn't able to do it, even when before I deleted my initial root page. I'm new to Wagtail, but I just simply forgot to add my new Django app with the Page model to my INSTALLED_APPS. This didn't raise any errors, just a simple oversight, but i ended up in this issue, so for some this information might help!

This issue still exists. I deleted the root page and now can not create a site or a new page.
I still see page ID 1 in wagtailcore_page but it appears to be inaccessible.
Can I flip a bit in one of the columns to re-enable it or run an SQL insert to replace it?

@raimondi1337 You need to define a HomePage model. https://docs.wagtail.org/en/stable/getting_started/tutorial.html#extend-the-homepage-model

@raimondi1337 You need to define a HomePage model. https://docs.wagtail.org/en/stable/getting_started/tutorial.html#extend-the-homepage-model

I fixed it by dropping every wagtail table, deleting every wagtail django migration, and rerunning django migrations

@raimondi1337 Deleting the migrations that are shipped within Wagtail is liable to break your database in ways that are very difficult to recover from - at the very least, it'll prevent you from upgrading to future Wagtail releases. If you think it's fixed things, then fine, but we won't be able to provide any support from this point forward.

@raimondi1337 Deleting the migrations that are shipped within Wagtail is liable to break your database in ways that are very difficult to recover from - at the very least, it'll prevent you from upgrading to future Wagtail releases. If you think it's fixed things, then fine, but we won't be able to provide any support from this point forward.

I just deleted the migration completed rows in django_migrations table, not the migrations themselves.
Nothing *should be orphaned 🤞
I'll update my comment to not mislead anyone else that reads it.
I had to go do most of the stuff in your link anyways. The "Integrate Django into an existing project" documentation implied to me that I could skip all of the other Getting Started steps.
Thanks for the support!

I've managed to get myself in this situation today - I'd set my homepage model to have an empty list for parent_page_types as I guess I imagined this would only allow it to exist on root, and the tutorial gives no indication of how to specify "This can only be a root page" (Or I suppose, "this can only be child of root, x, y, or z")


Chinese characters not being stored correctly

.+Please check the FAQ (frequently-asked questions) first. If you have other questions or something to report, please address the following:
+## PHP Driver version or file name
+5.6.1
+## SQL Server version
+2014 and 2017
+## Client operating system
+Windows 10
+## PHP version
+7.3.9
+## Microsoft ODBC Driver version
+17
+## Table schema
+CREATE TABLE mnu_user_alt (
user_id nvarchar(16) NOT NULL,
language_id nvarchar(5) NOT NULL,
user_name nvarchar(40) NOT NULL,
PRIMARY KEY (user_id, language_id)
);
+## Problem description
+If I enter Chinese characters such as 苏州工业园区 into a field on a web page and store it, it gets displayed as ??????.  If I look at the data in Management Studio I see ???????. However, if I run the query within Management Studio and then display it, it shows as 苏州工业园区 even in my PHP application.
+## Expected behavior and actual behavior
+I am using "characterSet" => "UTF-8" in my connection string, so I expect multi-byte characters to be stored correctly but this is not happening.
+## Repro code or steps to reproduce
Run the query through a PHP app and it stores the data incorrectly. Run the query through Management Studio and it stores the data properly.

hi @TonyMarston
You didn't specify which driver, but I assume you used the sqlsrv driver.
Please use the N prefix, as explained in our documentation about INSERT statements
Here is the extract:

When referencing the Unicode character data types nchar, nvarchar, and ntext, 'expression' should be prefixed with the capital letter 'N'. If 'N' is not specified, SQL Server converts the string to the code page that corresponds to the default collation of the database or column. Any characters not found in this code page are lost.

For example, your insert statement should be similar to this:
INSERT INTO mnu_user_alt (user_name) VALUES (N'苏州工业园区');
Alternatively, you can use input parameters, like this:
$params = array('苏州工业园区');
$tsql = "INSERT INTO mnu_user_alt (user_name) VALUES(?);";
$stmt = sqlsrv_query($conn, $tsql, $params);
if ($stmt === false) {
    var_dump(sqlsrv_errors());
}

How can I set the default collation of the database or column to UTF-8?

hi @TonyMarston , please check the online documentation, beginning with database collation and column collation.
If you need help with database design please ask in the SQL Server forums. I'm going to close this issue because this is not a driver issue.

I don't need help with database design, I just need proper instructions on how to read and write UTF-8 characters in my database. The page at https://docs.microsoft.com/en-us/sql/connect/php/how-to-send-and-retrieve-utf-8-data-using-built-in-utf-8-support?view=sql-server-2017 simply says that to send and retrieve UTF-8 data all I need do is specify "CharacterSet" => "UTF-8" in the connection data. You are now telling me that this data is incomplete. What a farce!

Please do note that the examples in the aforementioned page concerning how to send or retrieve UTF-8 data using sqlsrv have used parameters, as in my first reply to you. In such case, specifying "CharacterSet" => "UTF-8" in the connection string suffices.
It's with T-SQL insert statements that you have to do something extra. Anyway, have a good day.


Card scanned reports new ID, can't match user.

I didn't expect this one.
Yesterday I programmed 2 cards and one keyfob in the user list.  Yesterday each card would activate the lock.
Today, when I scan the same cards and keyfob, the ID seems to have changed and the card(s) / key(s) are not recognized by the system, and as a result, the lock doesn't activate.
Is this a bug?

Hello,
Thanks for using esp-rfid software. Some of the keyfobs may choose to implement what we call RID feature, in this case each time the keyfob is energized it simply generates a random UID. Currently esp-rfid can not work with these kind of RFID chips (tags, keyfobs, etc).
Kind regards.

I don't believe that is the case for these cards.  So far, any card that has had a different number appear when scanning has only alternated between two numbers.  Are you suggesting that when the antenna is charged, the chip on the card or keyfob responds with either a single code, or potentially a random code from either a list of codes embedded on the chip, or a randomly generated code on the fly?

What is the solution for this?  Every time I scan a card it presents a new user ID.  Naturally this won't work.  Is it the Weigand reader, or is it the card?  If it's the reader, which reader do I need?  If it's the card, which cards should I use.  I've been through 2 readers and 2 different sets of cards now and I have the same issue.


[e2e]: container-based push main multi slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/8562087181
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.push.main.multi.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.push.main.multi.slsa3.yml
Trigger: push
Branch: main
Date: Thu Apr  4 22:25:53 UTC 2024

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/8562304993
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.push.main.multi.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.push.main.multi.slsa3.yml
Trigger: push
Branch: main
Date: Thu Apr  4 23:29:25 UTC 2024
Tests are passing now. Closing this issue.


Fix helm-chart fuse hostpath type from File to CharDevice

In k8s 1.19+ , hostPathType needs to be more accurate, otherwise the following error will be reported:
MountVolume.SetUp failed for volume "alluxio-fuse-device" : hostPath type check failed: /dev/fuse is not a file

In Node use file command to check /dev/fuse type:
$ file fuse
fuse: character special (10/229)

So that Maybe we should change hostPathType from  File to CharDevice

Codecov Report

Merging #13181 (9e2288e) into master (6231603) will decrease coverage by 26.52%.
The diff coverage is n/a.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6231603...9e2288e. Read the comment docs.

@jiacheliu3
Hi~ Thanks for your reviewed !
I've changed CharDevice to BlockDevice and fuse can not started:
MountVolume.SetUp failed for volume "alluxio-fuse-device" : hostPath type check failed: /dev/fuse is not a block device

CharDevice is not a new type in k8s 1.19+, so that I think it can works in k8s below 1.19.

alluxio-bot, merge this please


Add a benchmark for portions of LitGPT model other than SDPA

This PR adds a new benchmark, run it with
pytest thunder/benchmarks/litgpt_chunks.py --benchmark-group-by='group,param:info' --benchmark-columns='min,max,mean,stddev,median'

The intent is to be able to compare performance on sections of the GPT network that are not covered by a FlashAttention kernel.
Constructing benchmark cases is slow and -s gives a progress bar:
Constructing benchmark cases for config: CodeLlama-13b-hf (1/39)
Constructing benchmark cases for config: CodeLlama-34b-hf (2/39)
Constructing benchmark cases for config: CodeLlama-70b-hf (3/39)
Constructing benchmark cases for config: CodeLlama-7b-hf (4/39)
Constructing benchmark cases for config: Gemma-2b-it (5/39)
Constructing benchmark cases for config: Gemma-7b-it (6/39)
Constructing benchmark cases for config: Mistral-7B-v0.1 (7/39)
Constructing benchmark cases for config: Nous-Hermes-13b (8/39)
Constructing benchmark cases for config: Nous-Hermes-Llama2-13b (9/39)
Constructing benchmark cases for config: Platypus2-70B (10/39)
Constructing benchmark cases for config: Platypus2-70B-instruct (11/39)
Constructing benchmark cases for config: RedPajama-INCITE-Instruct-3B-v1 (12/39)
Constructing benchmark cases for config: dolly-v2-12b (13/39)
Constructing benchmark cases for config: dolly-v2-3b (14/39)
Constructing benchmark cases for config: dolly-v2-7b (15/39)
Constructing benchmark cases for config: falcon-180B-chat (16/39)
Constructing benchmark cases for config: falcon-40b-instruct (17/39)
Constructing benchmark cases for config: falcon-7b-instruct (18/39)
Constructing benchmark cases for config: open_llama_3b (19/39)
Constructing benchmark cases for config: phi-1_5 (20/39)
Constructing benchmark cases for config: phi-2 (21/39)
Constructing benchmark cases for config: pythia-1.4b-deduped (22/39)
Constructing benchmark cases for config: pythia-12b-deduped (23/39)
Constructing benchmark cases for config: pythia-14m (24/39)
Constructing benchmark cases for config: pythia-160m-deduped (25/39)
Constructing benchmark cases for config: pythia-1b-deduped (26/39)
Constructing benchmark cases for config: pythia-2.8b-deduped (27/39)
Constructing benchmark cases for config: pythia-31m (28/39)
Constructing benchmark cases for config: pythia-410m-deduped (29/39)
Constructing benchmark cases for config: pythia-6.9b-deduped (30/39)
Constructing benchmark cases for config: pythia-70m-deduped (31/39)
Constructing benchmark cases for config: stablecode-instruct-alpha-3b (32/39)
Constructing benchmark cases for config: stablelm-tuned-alpha-3b (33/39)
Constructing benchmark cases for config: stablelm-tuned-alpha-7b (34/39)
Constructing benchmark cases for config: stablelm-zephyr-3b (35/39)
Constructing benchmark cases for config: tiny-llama-1.1b-chat (36/39)
Constructing benchmark cases for config: vicuna-13b-v1.5-16k (37/39)
Constructing benchmark cases for config: vicuna-33b-v1.3 (38/39)
Constructing benchmark cases for config: vicuna-7b-v1.5-16k (39/39)

and it takes 6 minutes to generate the test cases:
468 tests collected in 377.53s (0:06:17)

It's possible to control the batch size by modifying BATCH_SIZE in litgpt_chunks.py and which configs to benchmark can be controlled by modifying the CONFIG_NAMES list.
Thunder is used for tracing the litgpt code and then the trace is split into chunks with the SDPA call as a delimiter. Since the GPT model has a for-loop structure it's enough to trace a model with just two transformer blocks. It gives the following program chunks:

Embedding (https://github.com/Lightning-AI/litgpt/blob/78bd4cae1e655359e92e7c7b830fcbaa4c15c152/litgpt/model.py#L89-L91) -> Beginning of a transformer block until SDPA
From one SDPA call to another (so merging the end and start of a transformer block)
End of a transformer block -> ln_f+lm_head (https://github.com/Lightning-AI/litgpt/blob/78bd4cae1e655359e92e7c7b830fcbaa4c15c152/litgpt/model.py#L95-L96)

We could save the result of generating test cases to a disk, but that's left as an exercise for the future.
TODO:

[ ] Run the benchmark on H100

cc @crcrpar @kevinstephano

I've put it to draft to prevent merging because I need more time to think about it and convince myself again that it's something we need in the project.
I prefer to keep it in the draft stage to remind myself about it every day.

"draft" is the new browser tab haha


Added Everything 1.5a to Applications (Includes Dark mode)

This is the same publisher as the Everything Search already included, but has a dark theme (among numerous other improvements)
Don't get intimidated by the "Alpha" software release life cycle, it was released on 2021-03-13 and has been very stable.
For more details, you can refer to the Everything 1.5a announcement here and the Winget package link here.

I don't want to bloat things up with betas or alpha software.


@Property not showing in editor

Not sure what do you mean but possibly will be fixed with beta5 update.
Possible reason is that in register.d:505 there is a line like that, it has a comma instead of semicolon and that has effect of moving a type declaration only if that static if is true.
Very hard to track bug.
register.d:505:
static if (Variant.variantTypeOf!P == VariantType.object)
    pinfo.class_name = godotName!(P).ptr,
pinfo.type = vt;

Ok even though in editor help now all properties are visible some of them are not listed in inspector, in test project dreal and freal are missing, probably a number too.
Just to be clear, it seems only auto properties are affected, i.e. normal D field with @Property attribute.

Godot properties are managed by godot itself
Need to look at cpp implementation to figure out what's going on

Ugh, I mean they are indeed got registered, but they are not showing in the inspector because of incorrect flags combination or something like that.

Oh, sorry, misunderstood
Still better check cpp to see what we have wrong

As a fair warning, I made stuff in C++ where sometimes they arent working in the editor, I would have to restart the editor once or twice and sometimes with working code STILL not working, have to nuke the .godot folder and restart before they would work. Might check that process and confirm its actually definitely not working and not a godot bug before stressing too hard.

Property variables (freal and dreal in test project) should have correct flags set in api.register.register()
api/register.d:
// somewhere under this foreach
static foreach (pName; godotPropertyVariableNames!T) {
    // ...
    import godot.globalenums : PropertyUsageFlags;
    pinfo.usage = PropertyUsageFlags.propertyUsageDefault; // <-- this!
    // ...
}

Last time I checked godot-cpp with debugger it has usage=7 which is propertyUsageDefault | 1 but there is no flag for 1, anyway default is enough.

Fixed with #95


Round corners on Windows 11 cause blank edges on Windows Terminal

Windows Terminal version (or Windows build number)
10.0.22000.0
Other Software
No response
Steps to reproduce
Just open up the Windows Terminal app.

Expected Behavior
No blank edges.
Actual Behavior
The window corner resizing to make it rounder doesn't actually work well on this particular app.

This problem doesn't happen when executing the Windows Terminal app on dark mode.

Thanks for the feedback! I've made sure to pass this along to the DWM team. They're still hard at work rounding out heh the kinks in this feature before the official release.


0.4.2: diffie-hellman cannot find ./lib/primes

Hello,
Looks like the update from a couple hours ago could be bringing in a bug with a downstream dependency.
Dependencies go:

webpack 1.5.1 depends on node-libs-browser ~0.4.0
node-libs-browser 0.4.2 depends on crypto-browserify ^3.9.13
crypto-browserify 3.9.13 depends on diffie-hellman ^3.0.1
diffie-hellman 3.0.1 breaks

Error in browser is: Cannot find module "./lib/primes", which is required from diffie-hellman/browser.js
Looks like there exists a ./lib/primes.json in that package, so maybe configuring webpack to auto check ".json" suffixes would work, I'll try that.
Will also learn about npm-shrinkwrap after this.
Any other tips for resolving issue?  Thank you.

To downgrade and workaround temporarily (for anyone else that finds this thread and has the same issue:
npm install --save<EMAIL_ADDRESS>rm -Rf node_modules/webpack
npm install

This will add an explicit dependency in your package.json for<EMAIL_ADDRESS>so be sure to remove in that future when this issue is resolved.

@sokra Wow, this was kind of unexpected from upgrading my webpack version... Everything that I have relied on that crypto shim is now broken. The version there does have any AES function implemented

Fixed. See https://github.com/crypto-browserify/diffie-hellman/pull/21

I receive this same error using v2.1.0-beta6. has this been fixed?

still broken in<EMAIL_ADDRESS>

@UnsungHero97  this work well just want to point that by defualt node_modules are included so you don't need to add
include: [
/node_modules/
]

@UnsungHero97 The version of node-libs-browser used by Webpack 2 was updated back in January (unfortunately, the v1 branch still hasn't upgraded). In any case, by the time 2.1.0-beta.7 was released the version of crypto-browserify should have had the fixes need for diffie-hellman.
If you're still having the problem, can you give the "crypto-browserify" portion of the tree output from npm ls? I'd really like to hunt it down and resolve it.

@terinjokes thats my output for npm ls crypto-browserify:
/var/www/html/filecloudprod
└─┬<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ └─┬<EMAIL_ADDRESS>│   └──<EMAIL_ADDRESS>└─┬<EMAIL_ADDRESS>(git://github.com/jeroennoten/webpack-stream.git#d78a3568e259f9cdbc64c60290639af6ef6d3baf)
└─┬<EMAIL_ADDRESS>└─┬<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>I still get the error, but working with laravel 5.3.
Look at my post at stackoverflow.


Distance from location shall access places list from GSAK

It would be nice to access the places defined in GSAK

This is already present.
However, the locations are read from the GSAK database once at startup of GSAKWrapper. They are then presnt in the drop down list of the filter 'Distance from location'

I always get empty drop down list.
Wanted to add screen shot but I'm not able to upload.


First review feedback / ideas

Didn’t know where to put the feedback for the ftp poller demo, so just dumping it all here:

[ ] There’s a typo in the npm run configure-parners  <-- missing t

[ ] Would you consider adding a quick Zod schema to validate the trading partner JSON? You could infer your runtime types from it too (we’re using it a lot in RealTruck to validate all sorts of structures, I think its a great pattern to catch translation/input issues).

[ ] The top level items key is very generic and somewhat confusing, I’d expect something more like partners or profiles.

[ ] The sample data we’re using like ANOTHERMERCH is very weak, I know you’re just copying from my earlier demos, but maybe we should pick a few nicer fake company names like Stark Inc or STARK01002 something that’s a bit more real looking and easier to relate too, maybe even MY_PARTNER_ISA ?

[ ] When I run the invoke-sftp-poller script, there’s no output - maybe sprinkle in a few console.logs - I had no clue where the data was going - and I ran it on an SFTP with 20+ files, so it just sat there .  I CRTL+C after a few minutes, so maybe I missed the final output.

[ ] I think you’ve got a prefixed / when you’re writing to the target bucket, I had a folder with just / as the name and inside that I had the trading-partners  directory. See screenshot.

[ ] I’d expect to be able to configure where the data is going, dumping onto the default sftp bucket feels a touch dangerous, even for a demo. Maybe spin up a dedicated bucket? And/or allow supplying a base path where all files get dropped, it could default to trading-partners - and maybe explain what file structure the files will be placed into by the script in the README?

[ ] I had  a few niggles with the README text too, I can submit a PR for that, or better, get our man in the kingdom by the sea to do a review.

Overall it was great, it worked first time - all of the above is just quality of life improvements.

[ ]  There’s a typo in the npm run configure-parners  <-- missing t

good catch! I should have copied and pasted

[ ]  Would you consider adding a quick Zod schema to validate the trading partner JSON? You could infer your runtime types from it too (we’re using it a lot in RealTruck to validate all sorts of structures, I think its a great pattern to catch translation/input issues).

I am actually using a quicktype schema which does the same. IMO it's even easier to get up and going compared to Zod. If you try with an invalid schema and run the configure-partners script you will see a validation error.

[ ]  The top level items key is very generic and somewhat confusing, I’d expect something more like partners or profiles.

I used items to align with the Stash ListValuesCommand response. This way the same quicktype generated type can be used to validate the configuration and the Stash response. I can document the reasoning if you think it makes sense to do so.

[ ]  The sample data we’re using like ANOTHERMERCH is very weak, I know you’re just copying from my earlier demos, but maybe we should pick a few nicer fake company names like Stark Inc or STARK01002 something that’s a bit more real looking and easier to relate too, maybe even MY_PARTNER_ISA ?
Yeah, this is a good call -- I can update this across our demos. I wanted to keep it consistent, but agreed we should use a better name.

[ ]  When I run the invoke-sftp-poller script, there’s no output - maybe sprinkle in a few console.logs - I had no clue where the data was going - and I ran it on an SFTP with 20+ files, so it just sat there .  I CRTL+C after a few minutes, so maybe I missed the final output.

Ahh, yep, I bet you just cancelled too early. I will sprinkle in some output messages.

[ ]  I think you’ve got a prefixed / when you’re writing to the target bucket, I had a folder with just / as the name and inside that I had the trading-partners  directory. See screenshot.

I noticed this yesterday as well -- I thought that the PutObjectCommand key supported both relative and absolute paths (and it actually seems to, because the object gets uploaded successfully). I'm wondering if this is a Buckets UI issue?
Interestingly, when uploaded with the preceding / the bucket notification comes in as expected and gets processed by the read EDI handler that I have deployed. Maybe it's getting a notification with a double leading / though. Will check.

[ ]  I’d expect to be able to configure where the data is going, dumping onto the default sftp bucket feels a touch dangerous, even for a demo. Maybe spin up a dedicated bucket? And/or allow supplying a base path where all files get dropped, it could default to trading-partners - and maybe explain what file structure the files will be placed into by the script in the README?

I can definitely make it configurable. I think putting it in the default sftp bucket is actually a good idea -- the input files can be processed in the same manner as input files that are received by partners using Stedi SFTP. I would be interested in hearing more about what feels dangerous to you with this approach.

[ ]  I had  a few niggles with the README text too, I can submit a PR for that, or better, get our man in the kingdom by the sea to do a review.

A PR would be welcome! I did ping Joost yesterday for his feedback, but would be happy to get your feedback incorporated too.

Overall it was great, it worked first time - all of the above is just quality of life improvements.

🙏 thank you for giving it a run through! The feedback is greatly appreciated

I am actually using a quicktype schema which does the same. IMO it's even easier to get up and going compared to Zod. If you try with an invalid schema and run the configure-partners script you will see a validation error.

I missed spelled  externalSftpConfig to externalSftpConfigs and it created the value in the Keyspace without issue, so I guess the validation isn't run by the configure-parners script?

I used items to align with the Stash ListValuesCommand response. This way the same quicktype generated type can be used to validate the configuration and the Stash response. I can document the reasoning if you think it makes sense to do so.

That's nice for your development experience, but from an approachability perspective I think a more descriptive name would help.

I can definitely make it configurable. I think putting it in the default sftp bucket is actually a good idea -- the input files can be processed in the same manner as input files that are received by partners using Stedi SFTP. I would be interested in hearing more about what feels dangerous to you with this approach.

Maybe if you explicitly call it out in the docs, I just felt blind as to where the files were going to go, it feels like it's too magical - I prefer complete visibility/control.

I missed spelled externalSftpConfig to externalSftpConfigs and it created the value in the Keyspace without issue, so I guess the validation isn't run by the configure-parners script?

ahh, interesting -- it does do the validation, but because externalSftpConfig is optional it won't fail if it's missing. does Zod throw an error for extra properties being present?

That's nice for your development experience, but from an approachability perspective I think a more descriptive name would help.

Sure, I can use separate types for the configuration and the Stash response

Maybe if you explicitly call it out in the docs, I just felt blind as to where the files were going to go, it feels like it's too magical - I prefer complete visibility/control.

yeah, I Think it makes sense to both call it out in the docs and to make it configurable

Maybe if you explicitly call it out in the docs, I just felt blind as to where the files were going to go, it feels like it's too magical - I prefer complete visibility/control.

yeah, I Think it makes sense to both call it out in the docs and to make it configurable

Following up on this: I can really only add a console.log to indicate that the function is being invoked (which I've done). I can't print anything to the console from the function itself though, as it's running in the Stedi cloud / Lambda environment.

I can definitely make it configurable. I think putting it in the default sftp bucket is actually a good idea -- the input files can be processed in the same manner as input files that are received by partners using Stedi SFTP. I would be interested in hearing more about what feels dangerous to you with this approach.

Maybe if you explicitly call it out in the docs, I just felt blind as to where the files were going to go, it feels like it's too magical - I prefer complete visibility/control.

I ended up adding this to the trading partner profile schema... configurable per partner now!:
  bucketConfig?:       BucketConfig        // optional path prefixes used for reading/writing files for this trading partner


Filters stored as URL params are acting weird

Steps to reproduce:
Open an embed, for example
https://team.cartodb.com/u/solutions/builder/16ab12f6-3c57-11e6-bee9-0e674067d321/embed
Zoom to the place with a high concentration of green markers and do not touch anything else. Total stores: 14,973
Refresh the window --> Total Stores: 165, but (visually at least) there is no filtering applied to any widget.
Refresh again -> no change

possibly duplicated by https://github.com/CartoDB/cartodb/issues/8227

by this very issue? :joy:

Fixed long time ago


GHE 3.10.3 / pnpm monorepo / only root package.json dependencies are updated

Is there an existing issue for this?

[X] I have searched the existing issues

Package ecosystem
pnpm
Package manager version
8.7.6
Language version
Node.js  v20.8.1
Manifest location and content before the Dependabot update
package.json
pnpm-lock.yaml
pnpm-workspace.yaml
apps/myapp1/package.json
apps/myapp2/package.json
dependabot.yml content
version: 2
updates:

package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
open-pull-requests-limit: 5
rebase-strategy: "auto"
versioning-strategy: increase

Updated dependency
No response
What you expected to see, versus what you actually saw
I'm expecting the myapp1 and myapp2 dependencies to be updated
Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
No response

Pay 10 Eth to 0xbB422Eafc1a7998C4Fc8c7E08bd60D870DE48152

not sure what happened, but it's working now 🤷♂
closing this.


Event willPaste won't react on image

While pasting simple image which is in clipboard, willPaste event listener won't react to it, it only reacts to the text.
Expected result would be to handle image pasting too.

how to do this is shown here
#425 Can't paste image from clipboard into demo


Fixes layershells not being able to steal focus from windows as described in #4968.
Fixes use after free in m_dExclusiveLSes when exclusive state changes post-map.

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

Changing the keyboard focus mode to none will not kick the layer from the seat, even though refocus is called.

Is it ready for merging, or does it need work?
Ready to merge.

Will deal with that tomorrow. Also noticing that, unlike in a nested session, in a root session any mouse presses will result in a press->release if the surface has keyboard interactivity. Don't think this one is my bug due to basically just copying what you did but I'll also take a look tomorrow.

Debugged the weird press-release thing mentioned above https://github.com/hyprwm/Hyprland/issues/6409

generally code is ok

ran clang format, thats just unrelated junk from it

undid unrelated c-f stuff


Avoid console popup

It seems a shame that the nice GUI actually does all its work in a separate console that it spawns, without progress or GUI elements. Would be gently nice to fix that.

We now advise people use Stack instead, MinGHC is no longer supported.


Add back button to Credits activity

I think this activity has to have a back button in appBar. I missed it when I tried to use the app

Great! Thank you very much @Yahhi . I'll be sure to push this live shortly


Debug symbols for release builds

Feedback appreciated on this one.  My first shot at this was to just include debug symbols in the output ELF.  That in and of itself, however, still did not result in me being able to do anything useful as far as debugging the blink example (which I happened to be using for my testing).  I think this is because of the optimizations (lots of inlining for sure).
Debugging works well with the "dev" profile which is defaulted to by cargo when --release is dropped.

LGTM, but we're not using the lieutenant workflow, so pull requests to the master branch of forks don't make sense because the master branch of a fork means nothing except possibly to the owner of the fork. (PRs to current topic branches in forks, however, would make perfect sense (ex. #3)). You'll want to re-open this upstream.

Haha, oops.  I did not intend to open the PR against the fork.  Github must have noticed that I had done this previously and assumed this is what I wanted now.  Not sure.  Will open against upstream.


Do not run the coverage action on 'main' branch

Signed-off-by: Maciej Szlosarczyk<EMAIL_ADDRESS>

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from maciej-szlosarczyk. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

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

LGTM label has been added.  Git tree hash: e5dda871d7319ac3111f81019605b6dd3edc3ec3

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: zacaaron
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [zacaaron]

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


fix: safer intent extra checks

Changes

Title

Does this fix a crash?

Not sure, but better safe than sorry


Add link to qtcreator setup wiki page

This is helpful for people coming in with no knowledge of developing for the reMarkable and just want to install draft.

Thanks!


Patch OLED menu encoder dysfunctional on dev branch

An update on the dev branch appears to have left the OLED encoder non-functional on the Daisy Patch (possibly also Field?). There have been a lot of updates recently including an update to libdaisy, which may be a cause?
Investigate and remedy.

I can't reproduce the error from the Node.js command line nor from the Max interface when trying a variety of multi-app patch examples.


Why did the npm version dip?

v0.1.61 existed, then it was mysteriously decreased to v0.1.7 and has since increased to the current v0.1.21.
Why was that done?
It causes really confusing npm update behaviour:
$ npm install --save blessed
<EMAIL_ADDRESS>node_modules/blessed
$ npm update
<EMAIL_ADDRESS>node_modules/blessed

For a log of versions on npm and when they were published:
npm view --json blessed | jq '.time'

Yikes, that v0.1.61 is supposed to be 0.1.6-1. I could remove v0.1.61 from npm but that might break existing projects. It looks like we're in for an early bump to v0.2.0 because of this.

So, changing npm wasn't an option since I don't want any projects that rely on 0.1.21 to break. I've bumped the latest version to v0.1.80. Thanks for bringing this up.

Sounds good. Thanks for responding so fast again. :sparkles:


[BUG] Unhandling loopback source when sbc under NAT

trigger by #54

fix nat ignore for proxy on loopback network #1719


Current selected profile notification

Is your feature request related to a problem? Please describe.
Recently I've set up 2 profiles in the player, and it's happened several times already where I've mined a few cards, only to realise I've had the wrong profile selected. This results in me having to go back to these recently created cards and "fix" them.
Describe the solution you'd like
I think it'd be good to have some sort of notification / confirmation to indicate the currently selected profile. This would make it more obvious and minimise the number of such mistakes, where the wrong profile is selected
Describe alternatives you've considered
The notification could be displayed:

On the subtitle load popup. E.g. Currently selected profile: XYZ above the `Subtitles must be loaded before you can start mining.
Display a new popup after loading the subtitles using the standard notification, e.g. ASB player extension successfully loaded using profile XYZ

Happy to add this myself if we're happy with the text / its location

This is a good idea and I think both places you suggested make sense, especially the "loaded" notification, since that will account for all users including those who drag and drop subtitle files.
But I think just adding info to the existing message might be too simplistic because there the "loaded" message already takes a lot of space. I would suggest applying a max length to the displayed message, truncating the subtitle file name using elipses...
Then something short and simple afterwards like "Profile: xyz" only if a non default profile is being used.
About the subtitle track selector dialog, I think this also requires thought but I dont know of a great solution. I would like the selected profile + settings button to be somewhat close together since those are related.


How to show gallery button on camera

I want to default the camera screen and a gallery icon should show at the bottom left. Is it possible?

You can customize the camera' UI via UIDelegate.


Crash without error reporting if no font is specified

Hot to reproduce: Create a new document, and a page inside of it. Then CellFormat(...) before setting the font.
This command and any other command following it will fail to execute, without any warning or error returned.

Thanks, @alialamine -- I'll investigate.

An error is now explicitly returned when attempting to render text without first having set the font.
Thanks for reporting this, @alialamine.

Ty. And nice work on the library. I think we can close this now.


Add support for Windows

https://elixirforum.com/t/nmake-fatal-error-u1052-file-makefile-win-not-found-vix-image/52208

Could be addressed together with support for pre-compiled binaries: https://github.com/akash-akya/vix/issues/77#issuecomment-1307024371

Hi @mrdotb,
That's great news! Creating Makefile is the correct first step. I have to take a closer look, but thanks for the trying it out and sharing! Been bit busy with current job, hopefully I'll get some time next month to do this.

Any updates on this issue?
Is there a way to use Vix on Windows without using WSL?

Hey @ramyma,
Unfortunately there is no progress. I do want to provide support for windows but blocker for me is that I don't have a windows system at hand to experiment and test. The mac laptop I have does not have enough space left to run windows inside VM.
I'll try to make room and run windows vm in sometime but not sure about the timeline.
Thanks

Thanks @akash-akya, I hope it's not too hard to get around; I'm trying to distribute an application on Windows, and I hit a wall due to this issue.
Please let me know if I can help you out somehow.
I appreciate your effort :pray:

@akash-akya Is there a chance we can get native Windows support?

Hey @ramyma, sorry for the late response.
As for the Windows support, unfortunately my situation is still same as https://github.com/akash-akya/vix/issues/79#issuecomment-1874921575. Even if I add support now, maintaining it will take some constant effort without a first-hand device. Especially so because libvips has a lot of libraries which gets updated frequently.
That said, I'll see if I can get a working version first, later we'll see about maintaining it.

Thanks, appreciated!


PlayerCollectionViewCell glitches during drag and drop

Moving the players causes the moved cell to glitch. Adopting the drag and drop API should be considered.

Turns out this is due to the UILongPressGestureRecognizer ending far earlier than I thought. Increasing longPressGestureRecognizer.allowableMovement  does not seem to solve the problem. Will have to investigate further.


Docs Authoring Pack for Visual Studio Code deprecated

Its repo has been archived.  If it's still supported, where should I report a technical issue?  Thanks.

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

ID: 7b26339c-9a3c-de93-7806-3eb105b16ae4
Version Independent ID: ec4aa25b-c7e2-db46-3cf1-7563e8031bd6
Content: Docs Authoring Pack for Visual Studio Code - Contributor Guide
Content Source: Contribute/how-to-write-docs-auth-pack.md
Product: non-product-specific
GitHub Login: @meganbradley
Microsoft Alias: mbradley

@meganbradley - Can you please assist with this question from the public-facing Docs contributor guide?

@rootsmusic - Thanks for bringing this to our attention. We're working internally to find an answer for you.

Ok @carlyrevier, assigned?

Unfortunately, we don't have a replacement solution for submitting feedback right now. The tool is still available for use, but we haven't identified a new place to submit feedback. Sorry for the inconvenience.

@rootsmusic - According to the product owner, you can still submit issues to the Docs Authoring Pack (now renamed Microsoft Learn Authoring Pack) repo, even though they aren't accepting public contributions to update the tool itself.
There's a PR open now to add the following sentence to the readme file to clarify this issue:
To submit feedback on the Microsoft Learn Authoring Pack, create an issue in this repository. Please don't share sensitive or personal information. We're not accepting outside contributions, but will review issues regularly to continue improving the existing extensions.

Thanks @carlyrevier.  Please also correct the "Repository" link (under "Resources") in the VS Marketplace.


Please publish Cargo.lock with the crate

    Updating crates.io index
    Updating git repository `https://github.com/hoodie/notify-rust/`
error: the lock file needs to be updated but --locked was passed to prevent this

sure thing, how about now?

Thank you very much. :)
I see this is now also available as a crate. Could you try this to publish the lock file with the crate?:
https://github.com/rust-lang/cargo/issues/5654

That's not the default? I thought it published all checked in files automatically, I'll look

https://github.com/rust-lang/cargo/blob/0.31.0/src/cargo/sources/path.rs#L346-L349

I've learned unstable Cargo features require Cargo nightly. Will bump this once it's stabilized.

@polyzen ping

Cargo will be changed to always include Cargo.lock in the .crate file if the package has binaries or examples.


Make StringComparator deserialization case-insensitive

it'd be nice if we forced case sensitivity in Druid and didn't have to think about distinctions anywhere

I'm 👍  on this since it used to work, and it'd be good to not break existing callers.
Would also be down with making it case sensitive in 0.10.0.

@gianm okay, 👍


Code reuse between MemoFormItem and V2PayForm

Summary
Combine these split code into one
Steps to reproduce

Go to '...'
Click on '....'
Scroll down to '....'
See error

What is the current bug behavior?
What is the expected correct behavior?
Relevant logs and/or screenshots
Environment

Device/OS: [e.g. iOS]
Browser: [e.g. chrome, safari]
Hardware wallet: [e.g. Ledger w/ Metamask]

Duplicate of https://github.com/jbx-protocol/juice-interface/issues/1353


app check prior to next DISC

@dougoldenburg and @sgkang leave this weekend to present the DISC in Taiwan, Korea and Japan! To make sure things are running smoothly with the updated code, we need authors to open up their apps on azure notebooks and make sure that
(a) The notebook is up to date - ping me on slack if not
(b) The app runs without errors
(c) interactions with the apps work as expected (no duplicating plots etc).
Once you have checked an app, please edit this issue by putting a tick in the box below to give it your green-light

[x] DC_Building_Pseudosections.ipynb
[x] DC_Cylinder_2D.ipynb
[x] DC_Inversions.ipynb
[x] DC_Layer_Cylinder_2D.ipynb
[x] DC_Layer_Cylinder_2_5D.ipynb
[x] DC_LayeredEarth.ipynb
[x] DC_Overburden_2_5D.ipynb
[x] DC_Plate2_5D.ipynb
[x] DC_Plate_2D.ipynb
[x] DC_Sphere_Constant_E.ipynb
[x] FDEM_ElectricDipole_Wholespace.ipynb
[x] FDEM_Inductive_Sphere.ipynb
[x] FDEM_MagneticDipole_Wholespace.ipynb
[x] FDEM_Planewave_Reflection.ipynb
[x] FDEM_Planewave_Wholespace.ipynb
[x] FDEM_VMD_LayeredEarth.ipynb
[x] InductionRLcircuit_Harmonic.ipynb
[x] InductionRLcircuit_Transient.ipynb
[x] MarineCSEM_LayeredEarth.ipynb
[x] MT_LayeredEarth.ipynb
[x] PhyProp_ColeCole.ipynb
[x] TDEM_ElectricDipole_Wholespace.ipynb
[x] TDEM_HorizontalLoop_LayeredEarth.ipynb
[x] TDEM_MagneticDipole_Wholespace.ipynb
[x] TDEM_Planewave_Wholespace.ipynb

cc @thast, @dccowan, @sgkang, @micmitch

Made a few minor corrections to several of the DC apps and pushed the changes to the patch_apps branches of em_examples and em_apps. 2.5D DC apps were not updated on Azure but I think that once they are the duplicate interact slider panels should disappear.

Hi,
Here is the test results for my apps:
InductionRLcircuit_harmonic (works but updates plots a little slow)
InductionRLcircuit_transient (works and updates reasonably quickly)
FDEM_Inductive_Sphere (not uploaded to Azure)
Devin
On Thu, Jun 8, 2017 at 12:29 PM, Michael Mitchell<EMAIL_ADDRESS>wrote:

Made a few minor corrections to several of the DC apps and pushed the
changes to the patch_apps branches of em_examples and em_apps. 2.5D DC apps
were not updated on Azure but I think that once they are the duplicate
interact slider panels should disappear.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/geoscixyz/em_examples/issues/84#issuecomment-307203877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMXoGTUG3PB0lkBMn8VdasQylS8vp2Rlks5sCEudgaJpZM4NzbBG
.

Up to date on Master but not on Azure (display button cause duplication of the widgets):

DC_Layer_Cylinder_2_5D
DC_Plate2_5D

Thanks for your efforts everyone! I have updated azure to the most recent changes you all have made and uploaded the altered notebooks.


doc: fix x-mark inaccessibility

In the documentation, we were using the unicode
U+10102	AEGEAN CHECK MARK
to denote an "x mark" in a feature table. It is not rendered
in Windows (not included in the Segoe UI Symbols font).
This PR uses instead the more standard
U+2717	BALLOT X (cross)
which has wider support
Closes #3361

/ok-to-merge


Support for Linux?

To make it short:
It would be really nice if someone could provide binaries build-instructions for Linux (and probably for MacOS)-users in the future.

been thinking about this. will have to research but im not sure WPF is supported on linux yet? All the class libraries could be migrated to .net core or .net 5/6 but im not sure if UI can be built on linux/mac?

Just a bump & posting this in case anyone has an idea of what to make of this:
Any idea how to get it working via Proton, if there's even a chance that it could work?
I tried - it gave an error that it needs DotNet6 blabla. Sure, alright, installed that dep (via protontricks).
Now there is no error, but it seems like the launcher just crashes after a second or two without ever popping up.
Tried the same with Bottles, same result.
Finally launched it via the bottles cli because I wanted to see what kind of error happens (optimisic me: Maybe it's just something small I can fix like another missing dep).
This is with sys-wine-9.0 as runner (soda produces the same error):
info:  DXVK: v2.4
info:  Vulkan: Found vkGetInstanceProcAddr in winevulkan.dll @ 0x6ffffcc23f00
info:  Built-in extension providers:
info:    Platform WSI
info:    OpenVR
info:    OpenXR
info:  OpenVR: could not open registry key, status 2
info:  OpenVR: Failed to locate module
info:  Enabled instance extensions:
info:    VK_EXT_surface_maintenance1
info:    VK_KHR_get_surface_capabilities2
info:    VK_KHR_surface
info:    VK_KHR_win32_surface
info:  D3D9: VK_FORMAT_D24_UNORM_S8_UINT -> VK_FORMAT_D32_SFLOAT_S8_UINT
info:  AMD Custom GPU 0932 (RADV VANGOGH):
info:    Driver : radv 24.2.5
info:    Memory Heap[0]:
info:      Size: 3050 MiB
info:      Flags: 0x0
info:      Memory Type[2]: Property Flags = 0x6
info:      Memory Type[5]: Property Flags = 0xe
info:      Memory Type[6]: Property Flags = 0xe
info:      Memory Type[8]: Property Flags = 0xc6
info:      Memory Type[10]: Property Flags = 0xce
info:    Memory Heap[1]:
info:      Size: 6101 MiB
info:      Flags: 0x1
info:      Memory Type[0]: Property Flags = 0x1
info:      Memory Type[1]: Property Flags = 0x1
info:      Memory Type[3]: Property Flags = 0x7
info:      Memory Type[4]: Property Flags = 0x7
info:      Memory Type[7]: Property Flags = 0xc1
info:      Memory Type[9]: Property Flags = 0xc7
info:  Process set as DPI aware
01a0:err:eventlog:ReportEventW L"Application: TRRandomizer.exe\n"
01a0:err:eventlog:ReportEventW L"CoreCLR Version: 6.0.1623.17311\n"
01a0:err:eventlog:ReportEventW L".NET Version: 6.0.16\n"
01a0:err:eventlog:ReportEventW L"Description: The process was terminated due to an unhandled exception.\n"
01a0:err:eventlog:ReportEventW L"Exception Info: System.Windows.Markup.XamlParseException: The invocation of the constructor on type 'TRRandomizerView.Controls.FolderLoadControl' that matches the specified binding constraints threw an exception.\r\n"
01a0:err:eventlog:ReportEventW L" ---> System.ArgumentException: Value does not fall within the expected range. (Parameter 'handle')\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Drawing.Icon.FromHandle(IntPtr handle)\r\n"
01a0:err:eventlog:ReportEventW L"   at TRRandomizerView.Utilities.ControlUtils.DefaultIcons.GetStockIcon(UInt32 type, UInt32 size)\r\n"
01a0:err:eventlog:ReportEventW L"   at TRRandomizerView.Utilities.ControlUtils.DefaultIcons.get_FolderSmall()\r\n"
01a0:err:eventlog:ReportEventW L"   at TRRandomizerView.Controls.FolderLoadControl..ctor()\r\n"
01a0:err:eventlog:ReportEventW L"   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean wrapExceptions)\r\n"
01a0:err:eventlog:ReportEventW L"   --- End of inner exception stack trace ---\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Markup.XamlReader.RewrapException(Exception e, IXamlLineInfo lineInfo, Uri baseUri)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings settings, Uri baseUri)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Markup.WpfXamlLoader.LoadBaml(XamlReader xamlReader, Boolean skipJournaledProperties, Object rootObject, XamlAccessLevel accessLevel, Uri baseUri)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Markup.XamlReader.LoadBaml(Stream stream, ParserContext parserContext, Object parent, Boolean closeStream)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Application.LoadBamlStreamWithSyncInfo(Stream stream, ParserContext pc)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Application.LoadComponent(Uri resourceLocator, Boolean bSkipJournaledProperties)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Application.DoStartup()\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Application.<.ctor>b__1_0(Object unused)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Threading.DispatcherOperation.InvokeImpl()\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)\r\n"
01a0:err:eventlog:ReportEventW L"   at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(Object obj)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)\r\n"
01a0:err:eventlog:ReportEventW L"--- End of stack trace from previous location ---\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)\r\n"
01a0:err:eventlog:ReportEventW L"   at MS.Internal.CulturePreservingExecutionContext.Run(CulturePreservingExecutionContext executionContext, ContextCallback callback, Object state)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Threading.DispatcherOperation.Invoke()\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Threading.Dispatcher.ProcessQueue()\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)\r\n"
01a0:err:eventlog:ReportEventW L"   at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)\r\n"
01a0:err:eventlog:ReportEventW L"   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)\r\n"
01a0:err:eventlog:ReportEventW L"   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)\r\n"
01a0:err:eventlog:ReportEventW L"   at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Threading.Dispatcher.Run()\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Application.RunDispatcher(Object ignore)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Application.RunInternal(Window window)\r\n"
01a0:err:eventlog:ReportEventW L"   at System.Windows.Application.Run()\r\n"
01a0:err:eventlog:ReportEventW L"   at TRRandomizerView.App.Main()\n"
wine: Unhandled exception 0xe0434352 in thread 1a0 at address 00006FFFFFC23C87 (thread 01a0), starting debugger...

Cant make much of this error sadly, but who knows, maybe it's just a small thing that has an easy workaround for someone who can decipher this properly.

@Meleemaru2k Thanks for the info. The problem is it's trying to load a Windows icon into the UI, so is falling over as that involves trying to pull in from shell32.dll from the OS. But we can work around that by providing our own icons, which would be nice anyway as it removes unnecessary ties to the platform.
We recently got the other libraries working cross-platform, so it is just the UI that's problematic. Leave it with me, I'll see if we can get something sorted out. I'll post something here if I'm able to get somewhere, if you'd be willing to try it out?

@Meleemaru2k Could you try the build from the following page (under the Artifacts section)?
https://github.com/LostArtefacts/TR-Rando/actions/runs/11533350892

@lahm86 It launches with this!
Has some UI Flickers when actually randomizing, but that's a minor issue.
Takes a comparatively long time on 'finalizing tasks', like half a minute or so, which at first made me doubt it would finish properly but it did in the end. Launched the game and et-voila, it works! Tested it with TR2.
I'm gonna write down sort of a tutorial here for others that want to run it on Linux in a moment I guess, as it's not very straightforward for a non-techy person to get this running. :)
You're making a friend of mine very happy with this, thanks a lot!

Short guide:

Go into Steam Deck Desktop mode
For the next step: Rightclick the game on Steam -> browse local files
Do this: https://github.com/LostArtefacts/TR-Rando/blob/master/USING.md#tr-i-iii-remastered
Follow this https://github.com/flathub/com.github.Matoking.protontricks
Restart your Terminal and then => protontricks 2478970 dotnetdesktop6
Download the build @lahm86 provided & extract it anywhere
Rightclick on the TRRandomizer.exe -> open with -> protontricks-launcher
Choose the Tomb Raider Profile which should have (2478970) with it
If you can't navigate to the TR Files, do this instead and replace the number with 1,2 or 3:
\home\deck.local\share\Steam\steamapps\common\Tomb Raider I-III Remastered*2*\DATA
Paste it into the Folder Path in the File-browser and hit enter
Done

@Meleemaru2k Great! Thank you for testing this. I will update the docs to show that this method is possible on Linux and link to your guide above.
Ideally we would have a Linux-specific UI to provide wider support in the future, but that will need a lot of investigation. The flickering I imagine is because ultimately WPF shouldn't be able to run on Linux, but the wrappers you have in place are making that possible in some form, probably translating Windows calls to something native, but there must be some loss of quality along the way. But if it's a working solution for now, that's great.
Also, the delay you saw at the end is normal for the first randomization in TRR - see the comment here. The next time you randomize (the same game) there shouldn't be such a delay.


chore: bump cypress to v 11

SUMMARY

Per the cypress docs, this experimental flag should help with some of the chromium memory problems we've been seeing, but it needs at least v12 in order to do anything:
https://docs.cypress.io/guides/references/error-messages#The-Chromium-Renderer-process-just-crashed
Bumping this version to 11. We'll do 12 in a separate PR
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

I checked to see if we had tried this flag before, and sure enough @rusackas had a PR that enabled it, and then removed it because it wasn't supported in v10. (they added support in v12). So I'm trying my luck to see how easily I can bump to 12. 🤞

I think there's a way to upgrade with a GUI using npx if you're not already aware. I've been curious how well that works, maybe it'll be helpful for the next bumps.

Oh nice. I'll try that. There's also a PR already where someone did the difficult work of bumping to v13. I was thinking of reviving that PR.


feat(combo-box): make ComboBox slottable

Closes #1176
This PR adds a default slot to ComboBox so the consumer can customize each item slot using their own components or elements. This is more expressive than the itemToString prop.
The default slot includes the item and index as props.
<ComboBox
  titleText="Contact"
  placeholder="Select contact method"
  items={[
    { id: "0", text: "Slack" },
    { id: "1", text: "Email" },
    { id: "2", text: "Fax" },
  ]}
  let:item
  let:index
>
  {item.text} {item.id} {index}
</ComboBox>

Released in v0.62.0


Update sbt-scalafix to 0.9.33

Updates ch.epfl.scala:sbt-scalafix from 0.9.26 to 0.9.33.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "ch.epfl.scala", artifactId = "sbt-scalafix" } ]

labels: sbt-plugin-update, early-semver-minor, semver-spec-patch

Superseded by #63.


Support trusted root in cosign verification

Fixes #3700

Summary

We recently added partial trusted root support to cosign when you are verifying a protobuf bundle, but this did not cover the case where you are using an old bundle, or using disparate signed material on disk.
This implements trusted root support for those cases by assembling the materials into a protobuf bundle, thus fixing some TODOs from when we added protobuf bundle support.
Generally to test I would recommend signing something and then verifying it with a trusted root, like:
$ go run cmd/cosign/main.go sign-blob --identity-token='...' --output-certificate=detached.crt --output-signature=detached.sig ../sigstore-go/examples/sigstore-go-signing/hello_world.txt

$ go run cmd/cosign/main.go verify-blob --trusted-root=trusted_root.public.json --certificate=detached.crt --signature=detached.sig --certificate-oidc-issuer="https://token.actions.githubusercontent.com" --certificate-identity="https://github.com/sigstore-conformance/extremely-dangerous-public-oidc-beacon/.github/workflows/extremely-dangerous-oidc-beacon.yml@refs/heads/main" ../sigstore-go/examples/sigstore-go-signing/hello_world.txt

Or:
$ go run cmd/cosign/main.go attest-blob --identity-token='...' --bundle=old_bundle_attestation.json --type=something --predicate="../sigstore-go/examples/sigstore-go-signing/intoto.txt" ../sigstore-go/examples/sigstore-go-signing/hello_world.txt

$ go run cmd/cosign/main.go verify-blob-attestation --trusted-root=trusted_root.public.json --bundle=old_bundle_attestation.json --certificate-oidc-issuer="https://token.actions.githubusercontent.com" --certificate-identity="https://github.com/sigstore-conformance/extremely-dangerous-public-oidc-beacon/.github/workflows/extremely-dangerous-oidc-beacon.yml@refs/heads/main" --type=something ../sigstore-go/examples/sigstore-go-signing/hello_world.txt

It's also a good idea to test with a timestamp authority, although you need to create a trusted root file that corresponds to your chosen timestamp authority. For example:
$ go run cmd/cosign/main.go attest-blob --key=cosign.key --tlog-upload=false --timestamp-server-url="https://timestamp.githubapp.com/api/v1/timestamp" --rfc3161-timestamp-bundle="attest.ts" --output-signature=attest.sig --tlog-upload=false --type=something --predicate="../sigstore-go/examples/sigstore-go-signing/intoto.txt" ../sigstore-go/examples/sigstore-go-signing/hello_world.txt

$ go run cmd/cosign/main.go verify-blob-attestation --trusted-root=trusted_root_with_timestamps.public.json --use-signed-timestamps=true --insecure-ignore-tlog=true --key=cosign.pub --rfc3161-timestamp="attest.ts" --signature=attest.sig --type=something ../sigstore-go/examples/sigstore-go-signing/hello_world.txt

Release Note

Added support for using a protobuf trusted root to verify signed material, either on disk or in a legacy cosign bundle format (i.e. not the protobuf bundle format).

Documentation

N/A?

This addresses verify-blob*, what about container image verification? A trust root still needs to be provided in that case, right? Can #3700 be considered "Fixed" without that?

I have written up some more thoughts on what I wrote above regarding cosign's public API. Would love to have a discussion there: https://github.com/sigstore/cosign/issues/3879

Thanks for adding tests! Generally it's awesome to see the trusted root supported in verification. But I do have some concerns though that I'm not entirely sure how to address. My main concern is over the assembly/verification of a bundle with sigstore-go whenever a TrustedRoot is provided on these lines.
@cmurphy is working on TUF v2 support including support for the TrustedRoot, and her approach is to assemble the fields in CheckOpts from the TrustedRoot file from TUF. I think there's a good opportunity for code reuse here, as we can support the TrustedRoot using cosign's legacy code paths. I think that's a lot safer and less prone to bugs, and I would feel good about the consistent behavior when using the trusted root via TUF and via a CLI flag. I think it's important to preserve cosign's legacy verification logic as we switch to the TrustedRoot, as some of the features in cosign are difficult or unsupported in sigstore-go right now, for example the legacy container image verification code will be pretty difficult to implement correctly in sigstore-go.
Longer term, I think some variant of my proposal in https://github.com/sigstore/cosign/issues/3879 of adding a fields for root.TrustedMaterial to CheckOpts will be the best way to support trusted root for cosign's legacy verification. Currently, cosign centralizes all verification in verifyInternal, and adding first-class support for the trusted root there makes a lot sense to me, but it does bring challenges.
Would love to hear @haydentherapper and @cmurphy's thoughts on this prior to approving. Personally I would like to see the TUF v2 support and this PR share some logic, but I could be convinced otherwise.

Yeah, I think @cmurphy @codysoyland @haydentherapper and I need to align on approach here.
Essentially, I think the question boils down to "how should cosign perform verification when it has a trusted root file (obtained via TUF or otherwise supplied directly).
Option 1 is to take the trusted root contents, map it to CheckOpts, and use the existing cosign verification paths. That's what @cmurphy is doing with https://github.com/sigstore/cosign/pull/3844 and @codysoyland is proposing with https://github.com/sigstore/cosign/issues/3879.
Option 2 is to use sigstore-go to perform verification when there is a trusted root, which is what I'm proposing with this pull request.
The benefit of option 1 is lots of parts of cosign understand / expect CheckOpts, and so it's easy for the changes to be connected to many different parts of cosign.
A disadvantage of option 1 is that many parts of the existing cosign verification path assume there's only one set of verification material, whereas a trusted root has several sets of verification material with overlapping time ranges. I don't have a full list of places that would need to be updated, but looking through pkg/cosign/verify for example:

SCT verification assumes it should use the first chain: https://github.com/sigstore/cosign/blob/main/pkg/cosign/verify.go#L275-L282
VerifySet doesn't have a concept of if the key it's using to verify was valid when the content was signed: https://github.com/sigstore/cosign/blob/main/pkg/cosign/verify.go#L1312-L1330
TSA verification assumes a single valid chain is present: https://github.com/sigstore/cosign/blob/main/pkg/cosign/verify.go#L1156-L1161

A benefit of option 2 is that sigstore-go today supports trusted roots, and has had substantial testing and usage of those codepaths.
Disadvantages of option 2 are:

Support for trusted roots needs to be added per-command, as seen in this pull request
Interoperability between content signed with cosign and verified with sigstore-go isn't fully known. On the one hand, many scenarios were tested with https://github.com/sigstore/cosign/pull/3796, on the other hand, that uncovered this incompatibility with timestamps and attestations: https://github.com/sigstore/cosign/pull/3877

Support for trusted roots needs to be added per-command

Along these lines, there are potential pitfalls of missing commands that need a trust root, such as for signing, and needing to duplicate code if new commands are added.

Chiming in on this discussion, I haven't read over the code yet, sorry in advance if I say anything inaccurate related to the PR.
Part of the goal of "theseus" was to slowly replace parts of Cosign such that users should be minimally impacted with each major change, but after enough major revisions, we'll have Cosign into the state that we want [1].
With the previous PRs @steiza authored, Zach brought Cosign up to parity with the other Sigstore clients when using the public good instance. Implementing this by only using sigstore-go APIs and controlling execution of this code with a dedicated flag was the good choice, as this made it quicker to integrate and start getting users used to the "new" (new to Cosign users) bundle formats.
While using sigstore-go directly would let us iterate faster, this sounds more like a rewrite of Cosign than a slow, deliberate migration that lets us make small breaking changes over a number of major releases. For some context, Cosign v2 had soooo many breaking changes and we got a lot of community feedback around this. I think we'd still have users on Cosign v1 if we hadn't had to make a breaking change with the TUF metadata that forced users onto v2 (which we also received feedback on!). I want to avoid this mistake with Cosign v3, preserving as much of the same functionality as possible while making small breaking changes that users should be fine with (e.g removing all CLI flags for individual trust root material in favor of the trust root bundle -  same functionality, different format, and we can provide migration tools).
One of the other benefits of https://github.com/sigstore/cosign/issues/3879 is it being easier to review and know we have maintained parity. We have great e2e testing in Cosign now, and ideally our refactors will largely not touch e2e testing (except when handling a new format) which will give us confidence that we haven't broken any existing features.
I also recognize that the verification logic in Cosign is not up to par with the specification - we should discuss this more. This may be an area where we need to work around Cosign's limitations and document the gaps (e.g lack of validity window verification, assumptions that aren't present in in the spec). From there we can choose to either implement these gaps, or push forward for v3 knowing we have these gaps, and then tee up those fixes (either by directly using sigstore-go or implementing the gaps) for v4. Again my goal is small, deliberate changes that give us confidence we aren't unexpectedly changing Cosign's behavior and especially aren't changing it without a migration path.
[1] We need to agree on what the end goals are as well, but I roughly would summarize it as:

the CLI interface is greatly simplified when using PGI,
we retain support for self-managed keys/private PKI (possibly under a dedicated CLI subcommand),
blob signing code duplication between Cosign and sigstore-go is reduced,
code duplication is reduced across all commands,
the bundle spec for containers is implemented,
Cosign as an API - container signing and private PKI only, blob signing should use sigstore-go (this needs more discussion)

re: the chart in https://github.com/sigstore/cosign/pull/3844#issuecomment-2377196869 and Cody's chart above, my preference would be to use sigstore-go when we're using a verification bundle, and Cosign's verification in all other cases (when we are not provided a verification bundle). My reasons for this are:

If you have a verification bundle, you must have gotten it from sigstore-* or Cosign with the "use trusted root" flag.
If you want a verification bundle, we will provide tooling to convert detached material or old bundles into new bundles.
If you don't have a bundle and can't convert, then you need Cosign verification. This should be rare/unexpected/never happen (?), and if it does, then we know there's a gap to address.
We slowly modify Cosign's verification logic to be at par with sigstore-go, giving us confidence in both. Once there is parity, then we can refactor away Cosign's verification logic.

For how I think this should be rolled out:

Cosign v3 will change the default for signing to produce a bundle, meaning verification should also go through sigstore-go's verification flow. For trust roots, we will require the trust root bundle and remove all of the CLI flags for individual trust root material. For verifying signatures, we will support both the verification bundle and detached material - the former goes through sigstore-go, the latter through Cosign.
Cosign v4 will remove detached material and require bundles. At this point, all verification should route through sigstore-go, so we can also refactor the API and remove duplication (or save that for Cosign v5).

Note I haven't thought through the container story fully, so that needs to be accounted for as well.

I think we need someone to do a more thorough investigation on pkg/cosign/verify than the ~1.5 hours I spent coming up with the list of 3 issues above, so we have a more realistic idea of what this would entail. It's possible those 3 issues are the only ones, in which case I agree that it wouldn't be too heavy of a lift.

I can help with this, though realistically it'll be two weeks til I can. If we're OK waiting til then, I'll set up some time to walk through the code and if anyone's available, I'd be happy to review it with others. Otherwise, I'm also happy to validate what others find.

I also want to add that the legacy cosign container image signing logic with the Simple Signing envelope is something that I personally would like to deprecate

What is the reason to deprecate this? I wasn't around when these decisions were first made so I can't speak to why a simple signing envelope was chosen over another structure.

As another option, I think we should consider using Cosign's verification logic exclusively, especially if we add support for the validity checks for trusted root. Then we need:

An abstraction layer to compose a verification bundle after signing
An abstraction layer to decompose a verification bundle on verification into an OCI struct to pass to the Verify API
@cmurphy's PR to take a trusted root (obtained via TUF v2) and decompose it into the individual materials in CheckOpts (and @steiza's PR to do the same, but with a provided trusted root)
The internal changes to Cosign's Verify API to make it conformant with sigstore-go

The benefit with this approach is we know we will not break any clients, and it limits the Cosign v3 changes to exclusively be changes to the CLI interface (e.g. remove old bundle, remove detached trust root material). The downside is duplicated logic with sigstore-go and some additional work in Cosign, but ultimately if we are doing this work already for the non-bundle case like noted above, then we might as well just leverage Cosign everywhere.
Then Cosign v4 is a transition to sigstore-go as the signing/verification API. Since we've brought Cosign up to par with sigstore-go, we can enumerate all user journeys and test for breaking changes more easily.

I'm going to close this out for now. Parts of this were rolled into #3901, and I think trusted root verification generally will be handled via #3844.


[Bugs] AMF retransmits SecurityModeCommand even though it receives UEContextReleaseRequest.

Describe the bug
If AMF receives UContextReleaseRequest during waiting for SecurityModeComplete, it retransmits SecurityModeCommand because the Timer(T3560) is not stopped.
To Reproduce

UE/gNB -> 5GC    InitialUEMessage/RegistrationRequest
UE/gNB <- 5GC    DownLinkNASTransport/AuthenticationRequest
UE/gNB -> 5GC    UpLinkNASTransport/AuthenticationResponse
UE/gNB <- 5GC    DownLinkNASTransport/SecurityModeCommand
gNB    -> 5GC    UContextReleaseRequest
UE/gNB <- 5GC    DownLinkNASTransport/SecurityModeCommand(retry 4.ScurityModeCommand)

Expected behavior
Not retransmit SecurityModeCommand Message.
Environment (please complete the following information):
free5GC Version: 3.0.6
OS: Ubuntu 18.04
Kernel version: 5.0.0-23-generic
go version go1.14.4 linux/amd64
Trace File
PCAP File
Bugs_Retransmit.zip
Additional context
I have sent a PR.

Thanks for the PR.


Avoid cryptic Ninja error messages

The Problem To Be Solved
Some examples come without RTE directory content (which is actually a user problem).
But the message that you are getting in CI system is:
FAILED: kws.Release+AVH-SSE-300-U55/src/kws.Release+AVH-SSE-300-U55-stamp/kws.Release+AVH-SSE-300-U55-configure /home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/tmp/kws.Release+AVH-SSE-300-U55/src/kws.Release+AVH-SSE-300-U55-stamp/kws.Release+AVH-SSE-300-U55-configure
cd /home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/tmp/1 && /home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/.vcpkg/downloads/artifacts/2139c4c6/tools.kitware.cmake/3.28.4/bin/cmake -P /home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/tmp/kws.Release+AVH-SSE-300-U55/src/kws.Release+AVH-SSE-300-U55-stamp/kws.Release+AVH-SSE-300-U55-configure-.cmake && /home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/.vcpkg/downloads/artifacts/2139c4c6/tools.kitware.cmake/3.28.4/bin/cmake -E touch /home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/tmp/kws.Release+AVH-SSE-300-U55/src/kws.Release+AVH-SSE-300-U55-stamp/kws.Release+AVH-SSE-300-U55-configure
CMake Error at /home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/tmp/kws.Release+AVH-SSE-300-U55/src/kws.Release+AVH-SSE-300-U55-stamp/kws.Release+AVH-SSE-300-U55-configure-.cmake:49 (message):
  Command failed: 1

   '/home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/.vcpkg/downloads/artifacts/2139c4c6/tools.kitware.cmake/3.28.4/bin/cmake' '-G' 'Ninja' '-S' '/home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/tmp/kws.Release+AVH-SSE-300-U55' '-B' '/home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/tmp/1' '-DSOLUTION_ROOT=/home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples' '-DCMSIS_PACK_ROOT=/home/runner/.cache/arm/packs' '-DCMSIS_COMPILER_ROOT=/home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/.vcpkg/downloads/artifacts/2139c4c6/tools.open.cmsis.pack.cmsis.toolbox/2.5.0/etc'

  See also

    /home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/tmp/kws.Release+AVH-SSE-300-U55/src/kws.Release+AVH-SSE-300-U55-stamp/kws.Release+AVH-SSE-300-U55-configure-*.log

ninja: build stopped: subcommand failed.
error cbuild: exit status 1

This is very cryptic as the root cause are missing files in the RTE directory.
The Error Log of CMake shows:
CMake Error at components.cmake:216 (add_library):
  Cannot find source file:

    /home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/device/corstone/RTE/Device/SSE-300-MPS3/startup_SSE300MPS3.c
Call Stack (most recent call first):
  CMakeLists.txt:126 (include)

CMake Error at components.cmake:379 (add_library):
  Cannot find source file:

    /home/runner/work/mlek-cmsis-pack-examples/mlek-cmsis-pack-examples/common/RTE/Machine_Learning/debug_log.cpp
Call Stack (most recent call first):
  CMakeLists.txt:126 (include)

CMake Error at components.cmake:216 (add_library):
  No SOURCES given to target: ARM_Device_Startup_C_Startup_2_0_0
Call Stack (most recent call first):
  CMakeLists.txt:126 (include)

CMake Error at components.cmake:379 (add_library):
  No SOURCES given to target:
  tensorflow_Machine_Learning_TensorFlow_Kernel_Utils_1_23_2
Call Stack (most recent call first):
  CMakeLists.txt:126 (include)

CMake Generate step failed.  Build files cannot be regenerated correctly.

Suggest A Solution
Multiple solutions seem to be possible:

If the CMake Generate step fails, don't call Ninja and show the error log instead
Verify that all RTE files are present; issue an error when missing with hint to option --update-rte
Check at the level of csolution if the files are present (as this might be header files, this solution might be weak).

Test Case
See https://github.com/ReinhardKeil/mlek-cmsis-pack-examples/actions/workflows/Test-Version-2.yml - Build Test

Similar to #1678
Suggest to test it with PR https://github.com/Open-CMSIS-Pack/cbuild2cmake/pull/166

I believe this will be solved by #1694 + #1697 hence remove assigned to CMSIS-Toolbox 2.6.0 for now

Problem is mostly solved. Remaining issue is #1757


[SPARK-6597][Minor] Replace input:checkbox with input[type="checkbox"] in additional-metrics.js

In additional-metrics.js, there are some selector notation like input:checkbox but JQuery's official document says input[type="checkbox"] is better.
https://api.jquery.com/checkbox-selector/

Test build #29374 has started for   PR 5254 at commit a253bc4.

Test build #29374 has finished for   PR 5254 at commit a253bc4.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.
This patch does not change any dependencies.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/29374/
Test PASSed.

This sounds fine. Since the tests won't test it, have you had a chance to try the affected controls locally to verify they still work as expected? A manual test would be good to double-check.

Yeah, I'll check soon.

I've tested this change manually (compared the appearance between before changed and after changed for each check box)  and I think, it appears to work as expected.


Hi, I logged into my adalite wallet and I can not see any of my ada there, all I can see that the exact amount is on a adress which I can not get it from. I do not understand how this could have happened, as every time i log in through my trezor. Here are all my funds: https://cardanoscan.io/address/addr1qyq4v3sgkh9r8gc75gd6ltnz5ty74nra3s4m2ndt8ddw4ysp2erq3dw2xw33agsm47hx9gkfatx8mrptk4x6kw66a2fq87v2t0 if someone can help me I would be very thankfull.

OS
Your OS:
Versions
The db-sync version (eg cardano-db-sync --version):
PostgreSQL version:
Build/Install Method
The method you use to build or install cardano-db-sync:
Run method
The method you used to run cardano-db-sync (eg Nix/Docker/systemd/none):
Additional context
Add any other context about the problem here.
Problem Report
Please do not include screenshots or images, but instead cut and paste any relevant log messages
or errors.

This is an adalite wallet issue. If cardano scan says your funds are still there then they are still there.
Remember, your funds are stored on the blockchain not in your wallet. All you wallet does is hold your private keys so you can prove to the blockchain that the funds are yours.
I know nearly nothing of Adalite, but I suggest you find out how to contact their support services and ask them. Please be careful with people trying to contact you and scam you out of your ADA.

Thank you very much. Yes will do so.


aezeed: add new package implementing the aezeed cipher seed scheme

In this PR, we add a new package implementing the aezeed cipher
seed scheme (based on aez).
This is a new scheme developed that aims to overcome the
two major short comings of BIP39: a lack of a version, and a lack of a
wallet birthday. A lack a version means that wallets may not
necessarily know how to re-derive addresses during the recovery
process. A lack of a birthday means that wallets don’t know how far
back to look in the chain to ensure that they derive all the proper
user addresses. Additionally, BIP39 use a very weak KDF. We use
scrypt with modern parameters (n=32768, r=8, p=1). A set of benchmarks has
been added, on my laptop I get about 100ms per attempt):
⛰ go test -run=XXX -bench=.

goos: darwin
goarch: amd64
pkg: github.com/lightningnetwork/lnd/aezeed
BenchmarkToMnenonic-4     	      10	 102287840 ns/op
BenchmarkFromMnenonic-4   	      10	 105874973 ns/op
PASS
ok  	github.com/lightningnetwork/lnd/aezeed	3.036s

Aside from addressing the shortcomings of BIP 39 a cipher  seed
can: be upgraded, and have it's password changed,
Sample seed:
ability dance scatter raw fly dentist bar nominee exhaust wine snap super cost case coconut ticket spread funny grain chimney aspect business quiz ginger

Plaintext aezeed encoding
The aezeed scheme addresses these two drawbacks and adds a number of
desirable features. First, we start with the following plaintext seed:
1 byte internal version || 2 byte timestamp || 16 bytes of entropy

The version field is for wallets to be able to know how to re-derive
the keys of the wallet.
The 2 byte timestamp is expressed in Bitcoin Days Genesis, meaning that
the number of days since the timestamp in Bitcoin’s genesis block. This
allow us to save space, and also avoid using a wasteful level of
granularity. With the currently, this can express time up until 2188.
Finally, the entropy is raw entropy that should be used to derive
wallet’s HD root.
aezeed enciphering/deciperhing
Next, we’ll take the plaintext seed described above and encipher it to
procure a final cipher text. We’ll then take this cipher text (the
CipherSeed) and encode that using a 24-word mnemonic. The enciphering
process takes a user defined passphrase. If no passphrase is provided,
then the string “aezeed” will be used.
To encipher a plaintext seed (19 bytes) to arrive at an enciphered
cipher seed (33 bytes), we apply the following operations:

First we take the external version an append it to our buffer. The
external version describes how we encipher. For the first version
(version 0), we’ll use scrypt(n=32768, r=8, p=1) and aezeed.
Next, we’ll use scrypt (with the version 9 params) to generate a
strong key for encryption. We’ll generate a 32-byte key using 5 bytes
as a salt. The usage of the salt is meant to make the creation of
rainbow tables infeasible.
Next, the enciphering process. We use aez, modern AEAD with
nonce-misuse resistance properties. The important trait we exploit is
that it’s an arbitrary input length block cipher. Additionally, it
has what’s essentially a configurable MAC size. In our scheme we’ll use
a value of 8, which acts as a 64-bit checksum. We’ll encrypt with our
generated seed, and use an AD of (version || salt).
Finally, we’ll encode this 33-byte cipher text using the default
world list of BIP 39 to produce 24 english words.

Properties of the aezeed cipher seed
The aezeed cipher seed scheme has a few cool properties, notably:

The mnemonic itself is a cipher text, meaning leaving it in
plaintext is advisable if the user also set a passphrase. This is in
contrast to BIP 39 where the mnemonic alone (without a passrphase) may
be sufficient to steal funds.
A cipherseed can be modified to change the passphrase. This
means that if the users wants a stronger passphrase, they can decipher
(with the old passphrase), then encipher (with a new passphrase).
Compared to BIP 39, where if the users used a passphrase, since the
mapping is one way, they can’t change the passphrase of their existing
HD key chain.
A cipher seed can be upgraded. Since we have an external version,
offline tools can be provided to decipher using the old params, and
encipher using the new params. In the future if we change ciphers,
change scrypt, or just the parameters of scrypt, then users can easily
upgrade their seed with an offline tool.

This is fantastic! Exactly what we'd need to bring Electrum and BIP39 wallets into a common standard without compromising the benefits of each approach. Will you be submitting a BIP for this?

@jonathancross once we get a bit of real world usage, we may submit a BIP. For now, it fits our use case precisely, so we'd rather include it immediately in the next release, rather than trying to make it a standard from the get go. Since we have an external version, if anything changes in the process, then we can provide an upgrade tool for anyone with an existing tool.

interesting.
do you really need day granularity for the timestamp? you could use block_height//2016

@ecdsa tying the birthday to a particular block height would require the seed format to know about the parameters of the underlying chain. the rationale behind not doing so is that an aezeed can be used to secure keys on any/multiple chains without modification, while also being flexible enough to allow the same seed to add derivation paths for other currencies at a later time.
most importantly, using the block height in the birthday would require you to sync the [header] chain before creating the seed.
that aside, I believe your point is about potentially increasing the granularity? we definitely could increase it, though with day granularity we should be good until almost 2188. with 2-week intervals, it would approach the year 4251. note that this is only a bound on the birthday of the seed, not a bound on the seed's lifetime. IMO I think this is a happy medium in terms of granularity, has a super simple implementation, and works on any chain!

Alrighty, pushed out a fixup commit that adds the ability to detect if a word isn't in the original list, and also if the mnemonic was entered incorrectly.
@cfromknecht PTAL.

Super cool.

@Roasbeef can you clarify the purpose of the version number? is it there only in order to be able to upgrade the cipher (and the key derivation remains unspecified, as in BIP43) , or will it also be used to specify the key derivation?

@ecdsa there're two versions: external and internal.
The external version governs how to decipher the cipher seed. So: key derivation parameters, checksum verification, salt. In the future if we upgrade any of these parameters, users can use an offline tool to "upgrade" their seed.
The internal version is for the wallet. It tells that wallet how to go about re-deriving all the addresses for the user. Unlike the external version (in my mental model at least), wallets don't need to agree on what this value is, or how it should be interpreted. So for example a version of 0 could mean to a wallet: "use bip44". While a version of 1 could mean: "use bip49 and bip84". If a wallet gets the deciphered cipher seed, and doesn't recognize the version, then it should reject it.

I know this is already merged, but I wanted to propose an alternative for the birthday mechanism which strengthens the 'exclusion proof' property.
If one uses a block hash instead of a clock-time, it makes it cryptographically impossible to pick a future birthdate. Picking a future time undermines the utility of the birthdate for proving that no transactions would be present before a certain time. However, even an honest seed-creator can't preclude themselves from creating a future-timed seed. This is because a big reorg could place transactions created after the creation of the seed to before the creation of the seed.
Using a blockhash instead of clock-time doesn't solve this problem, but it allows us to detect that this has occurred and then revert to a chain scan up to the most-recent-ancestor of the header hash used.
To keep this from adding overhead to the seed, what can be done is to only allow using every 144th (e.g. bitcoin-day) header hash. This can be specified using the same 2 byte index, then the client simply has to fetch the header-hash from the network and include it. One must be careful to ensure that it is indeed the same blockhash, otherwise no addresses will be found. This risk can be mitigated by not using the indexing trick above to save 30 bytes (storing the header with the seed directly) or by making use of the aez checksum.


kmeans and one-dimensional vectors

Clustering one-dimensional data was only possible when storing it column-based. But a std::vector is interpreted as matrix with height=1.
See http://stackoverflow.com/questions/25077878/using-opencv-cvkmeans-with-one-dimensional-input
Backport to 2.4 may be needed

in the case of single data point there is ambiguity and your code interprets it differently from the existing version. If the goal is to handle std::vector correctly, probably _data.kind() should be taken into account.

Thanks for auditing! The only other (apart from the lines I changed) place where isrow is used is during the creation of the data matrix (see code). Would there be a problem if the step size is calculated differently?

@PhilLab, I think, step should be fine in this case. Still, the condition for isrow should probably be:

bool isrow = data0.rows == 1 && (data0.channels() > 1 || _data.kind() == _InputArray::STD_VECTOR);

ok, let's actually merge it in :+1:


Translated Index.md to hebrew

Wrote first draft in hebrew.

[ ] I have read freeCodeCamp's contribution guidelines.
[ ] My pull request has a descriptive title (not a vague title like Update index.md)
[ ] My pull request targets the master branch of freeCodeCamp.
[ ] None of my changes are plagiarized from another source without proper attribution.
[ ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Oops, i didn't want to merge but accidentally did.
Pardon me.

Thanks for your contribution @avivbyo - There are plans to expand in the future, but for now we do not support Hebrew so I am closing this. And for future reference, you did not complete the checklist in the PR template, and the file you changed is in the English folder, that's for English versions.
Thanks, and happy coding!


[WIP] Containerized riff init

As an alternative to using riff-cli to initialize a riff function, we can wrap the init functionality inside a container images. The images can operate on an attached disk with the function source.
Configuration via environment:

RIFF_INVOKER_PATHS: Path to the riff invoker.yaml, may be a local path or http
FUNCTION_ARTIFACT: Path to the function artifact, source code or jar file (attempts detection if not specified)
FUNCTION_HANDLER: Name of method or class to invoke (see specific invoker for detail)
FUNCTION_FILE_PATH: Path or directory used for the function (defaults to the current directory)
FUNCTION_NAME: The name of the function

This idea has been implemented as a "build template" in the new Knative compatible riff