Coloured Bar for Block kit

Description
I can use coloured side bar in attachments but I don't find that option in block kit. I would like to add coloured bar in the below block kit. As of now we are getting only white coloured bar. Is there any way that we can add customized colour bar for the block kit ?
{
	"blocks": [
		{
			"type": "rich_text",
			"elements": [
				{
					"type": "rich_text_quote",
					"elements": [
						{
							"type": "text",
							"text": "I am a basic rich text quote, \n\nI can have multiple paragraph breaks within the block."
						}
					]
				}
			]
		}
	]
}

What type of issue is this? (place an x in one of the [ ])

[ ] bug
[x ] enhancement (feature request)
[ ] question
[ ] documentation related
[ ] example code related
[ ] testing related
[ ] discussion

Requirements (place an x in each of the [ ])

[ x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[ x] I've read and agree to the Code of Conduct.
[x ] I've searched for any related issues and avoided creating a duplicate issue.

Expected result:

Actual result:

Attachments:
Logs, screenshots, screencast, sample project, funny gif, etc.

Hi @ms3sm2, thanks for asking the question!
When you pass an attachment that includes blocks inside, you can display color bar within a posted message.
{
  "attachments": [
    {
      "color": "#f2c744",
      "blocks": [
        {
          "type": "section",
          "text": {
            "type": "plain_text",
            "text": "This is a plain text section block."
          }
        }
      ]
    }
  ]
}

You can use chat.postMessage to use attachments: https://github.com/slackapi/slack-github-action?tab=readme-ov-file#technique-2-slack-api-method

Hi @seratch ,
I understand that Slack API attachments are deemed legacy and will be phased out shortly. Is this correct?

Attachments are indded no longer recommended for general rich message construction. That said, they won't be removed anytime soon since they are widely used by many apps worldwide. They may be phased out in the long run (say, in years), but there is no timeline for that as of today. Regarding this color bar use case, using blocks as an attachment is the only way to achieve this, so you can rely on it for now.


Move cerberus plugin overlay above ghosts

The plugin will now show the ghosts' attack style above their head, instead of in an overlay. This makes it feel more integrated into the game and makes it so you need to pay attention when killing cerb, while still helping colourblind people know what to pray.
https://i.imgur.com/0YxtOfC.gif

I made it the same as the gorilla plugin since that's what people are used to, I can try to get it looking similar to the ingame prayer overheads.
Not really, I just didn't see any reason for it to be there. I'll change it back if that's prefered.

We should not use the vanilla prayer style as we are not indicating what the npc will not take damage from, we are indicating what attack style the npc is using, which is very different.

We should use the same one as the gorilla plugin for the same reason as in the gorrila plugin. It should not look like the vanilla one because it does not do the same thing as the vanilla one.

Well I am just saying that it do not looks very good and I dont like it, and if magic wants to mess with plugins he should spend more effort than just copy/pasting code from other plugin.

I agree it does not look very good, but making it look like vanilla will create a much worse problem, so it should not do that. This and the gorilla plugin should look the same because they convey the same information.

I think the gorilla overlays look fine, and I wanted it to be the same as them. If anyone has any ideas on how to make it look better, feel free to chime in.

Well if you want to stick to use same overlay for both, make common method in OverlayUtil like we do for every single other common overlay we have and use it in both plugins

Jagex's recent statement prohibits Indicates what prayers to use in what order, for example in the Cerberus boss fight


fix: check if user rejected txs

closes #229
I found out that with the following code:
if (onTransferPrompt) {
   onTransferPrompt(params);
 }

const tx = await contract.call()

the prompt is displayed even if the contract call fails. We can fix this by simply moving the prompt below the contract call.

:tada: This PR is included in version 1.16.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.16.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


fix(link-with-icon): remove property set-by-enum

Related Ticket(s)
Followup to #11071
Description
This PR removes 's use of LINK_SIZE.LARGE to set the size property.
Changelog
Changed

Changed component internals to avoid rollup errors in extending projects

@andy-blum seems like there is a small build error, we can get this is in once its fixed 👍


Created a KB for new permissions breaking changes

Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the CODEOWNERS.
What Type of PR is This?

[X] Issue
[X] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[X] Tested Locally
[ ] Optional Screenshot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6601f8985792d7568add2494--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66028fb183e177c593f714d7--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6602ecba5c335e52463d9b1e--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6602fb478fb0ec61a78fba7d--harness-developer.netlify.app


Error when build and run JDK >8

I have some errors when build IOS + using your lib for connect websocket . I used JDK 11
java.lang.NoSuchMethodError: java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip(I)Ljava/nio/ByteBuffer;
java.lang.NoSuchMethodError: java.nio.ByteBuffer.mark(I)Ljava/nio/ByteBuffer;

I use jdk 11 for build ios

This issue happens when you compile with JDK 9+ and run with Java 8.
Here is an article that explains it in details: https://www.morling.dev/blog/bytebuffer-and-the-dreaded-nosuchmethoderror/
If you download the jar automatically using something like Maven or Gradle, this error shouldn't happen because the jar will be built correctly. If you compile it yourself, use the --release=8 option
If you need more help with this, post a link to your code.

Closing as solution is provided and no activity


Variable.addgrad with mismatched dtype might not cause error

Version: current mater 8565bad9334f6cc32cd70a9d79fd42f74eeec3c2
import chainer
import numpy as xp

a = chainer.Variable(xp.array([1, 1], 'float32'))
#a.grad = xp.array([3, 5], 'float32')

b = chainer.Variable(xp.array([2, 2], 'float64'))
b.grad = xp.array([4, 7], 'float64')

a.addgrad(b)

print(a.dtype, a.grad.dtype)

An error is expected but it results in the following output (indicating mismatched gradient dtype)
float32 float64

If the comment-out is removed, it becomes an error:
chainer.utils.type_check.InvalidType:
Invalid operation is performed in: _ + _ (Forward)

Expect: lhs.dtype == rhs.dtype
Actual: float64 != float32

It seems the Link test relies on this behavior (probably unintentionally) :
https://github.com/chainer/chainer/blob/v6.0.0rc1/tests/chainer_tests/test_link.py#L543
self.link.u.dtype is float64 whereas l.u.dtype is float32.

For the record, although the error message can be improved (and is by #7140), the expected error in the above example is now raised as expected, in the current master.


Front-end for B eth addresses

Add details after 1-1 with Angie and Eli

In planning, talked about: we will need balances, transaction history.
Talk with Adam about what is available...subgraph

Goal NOW: onboard Picarto. Product requirements:

Dashboard with B fund status.
Admin hits a button, which queries /addresses endpoint, and populates status of all mainnet Bs with their deposit and reserve.
Livepeer would manually reload funds on Bs

Automation not necessary for now since the only mainnet B is Labrador.
ATM stream_instances = picarto streams. No need for /stream_instances yet

Resulting Front-end to-dos:

Login button on the side http://localhost:3004/
Broadcaster Statuses button below to live button, which hits /addresses endpoint, and takes us to new broadcaster page
Broadcaster page with B statuses, displays all $$ statuses
Refresh button on Broadcaster page


QIF import broken

I tried to import data from an other app, HomeBank, as well as the example file given in #265 and the toaster says "0 transactions imported".
The format of the date in both files is correct (US date: MM/DD/YYYY).
I'm using the latest version at the time of writing, which is 2023.2.2.
A QIF file that is broken: test.zip

https://user-images.githubusercontent.com/17648453/225073475-4231c96d-fc74-4e01-9d69-18e3121e9e61.mp4
I can't reproduce it...works fine for me.

^ That's running V2023.3.0-beta1, but that release did not change QIF from the latest stable.

Sorry but everything is in french:
Capture vidéo du 2023-03-14 17-46-34.webm
There is nothing in the list after restarting.

It worked fine for me using GNOME version too.
Maybe it's because the application is in French.
If you run the app using en-US does it work?

I tried in english, and it works fine, so the issue might come from language translation.

I have to see what localization occurs for QIF...and i'll fix it.

I believe this line is the problem: https://github.com/nlogozzo/NickvisionMoney/blob/main/NickvisionMoney.Shared/Models/Account.cs#L1354
I believe the en_US culture needs to be passed to that DateTime function other wise it will try to parse the date with the current locale instead of en_US.
I'm not home right now so I can't make the change and test. Maybe @fsobolev can.

I'm not home right now so I can't make the change and test. Maybe @fsobolev can.

I will work on it.

I quickly tested the fix with the CI build, thanks you for the support!

Once #355 is merged, I'll release beta 2 with all the file fixes :)

https://github.com/nlogozzo/NickvisionMoney/releases/tag/2023.3.0-beta2

Using 2023.4.1 from flathub I'm also having issues importing a QIF with date format DD/MM/YYYY.
If I change the dates in the QIF, Denaro is able to import the file properly.

@kivutar As per docs: https://htmlpreview.github.io/?https://raw.githubusercontent.com/NickvisionApps/Denaro/2023.4.1/NickvisionMoney.Shared/Docs/html/C/import-export.html

Quicken Interchange Format (.qif)
Dates should be in English (US) format (MM/DD/YYYY).


Infinite ec_deployment.elasticsearch.config drift when using ec 0.6.0 and terraform 1.4.0

Readiness Checklist

[x] I am running the latest version
[x] I checked the documentation and found no answer
[x] I checked to make sure that this issue has not already been filed
[x] I am reporting the issue to the correct repository (for multi-repository projects)

Expected Behavior

$ terraform plan
No changes. Your infrastructure matches the configuration.

It should not try to recreate the cluster if we don't have any ec_deployment.elasticsearch.config set.
Current Behavior

With:
resource "ec_deployment" "REDACTED" {
  name                   = "REDACTED"
  region                 = "azure-westus2"
  version                = "7.16.3"
  deployment_template_id = "azure-io-optimized-v3"

  elasticsearch = {
    cold = {
      autoscaling = {}
    }

    config = {}

    coordinating = {
      autoscaling = {}
    }

    frozen = {
      autoscaling = {}
    }

    hot = {
      autoscaling = {}
    }

    master = {
      autoscaling = {}
    }

    ml = {
      autoscaling = {}
    }

    warm = {
      autoscaling = {}
    }
  }

  kibana = {}
}

I get this infinite diff:
$ terraform plan
Terraform will perform the following actions:

  # ec_deployment.REDACTED will be updated in-place
  ~ resource "ec_deployment" "REDACTED" {
      + apm_secret_token       = (sensitive value)
      ~ elasticsearch          = {
          ~ cloud_id       = "REDACTED" -> (known after apply)
          ~ config         = {
              + plugins = (known after apply)
            }
          ~ http_endpoint  = "REDACTED" -> (known after apply)
          ~ https_endpoint = "REDACTED" -> (known after apply)
          ~ resource_id    = "REDACTED" -> (known after apply)
            # (12 unchanged attributes hidden)
        }
        id                     = "REDACTED"
        name                   = "REDACTED"
        # (5 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

And with
    config = {
      plugins = []
    }

I get:
Terraform will perform the following actions:

  # ec_deployment.REDACTED will be updated in-place
  ~ resource "ec_deployment" "REDACTED" {
      + apm_secret_token       = (sensitive value)
      ~ elasticsearch          = {
          ~ cloud_id       = "REDACTED" -> (known after apply)
          ~ config         = {
              + plugins = []
            }
          ~ http_endpoint  = "REDACTED" -> (known after apply)
          ~ https_endpoint = "REDACTED" -> (known after apply)
          ~ resource_id    = "REDACTED" -> (known after apply)
            # (12 unchanged attributes hidden)
        }
        id                     = "REDACTED"
        name                   = "REDACTED"
        # (5 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

and finally without any config block I get:
Terraform will perform the following actions:

  # ec_deployment.REDACTED will be updated in-place
  ~ resource "ec_deployment" "REDACTED" {
      + apm_secret_token       = (sensitive value)
      ~ elasticsearch          = {
          ~ cloud_id       = "REDACTED" -> (known after apply)
          - config         = {} -> null
          ~ http_endpoint  = "REDACTED" -> (known after apply)
          ~ https_endpoint = "REDACTED" -> (known after apply)
          ~ resource_id    = "REDACTED" -> (known after apply)
            # (12 unchanged attributes hidden)
        }
        id                     = "REDACTED"
        name                   = "REDACTED"
        # (5 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

We don't have any way out with tf 1.4 and ec 0.6.
Steps to Reproduce

terraform plan

Possible Solution

This works with terraform v1.3.9 and ec v0.6.0
This works with terraform v1.4.0 and ec v0.5.1
This works with v1.3.9 and ec v0.5.1
This does not work with v1.4.0 and ec v0.6.0

So we have workarounds for now, but we had to rollback from ec v0.6.0 back to ec v0.5.1 to be able to upgrade terraform to v1.4
Your Environment

Terraform v1.4.0
on darwin_arm64
+ provider registry.terraform.io/elastic/ec v0.6.0

Same problematic behavior with ec 0.7.0, terraform 1.4.6.

It doesn't look like we've committed to a timeframe on this issue as yet sorry @Zawadidone.

We downgraded terraform from v1.4.x to v1.3.9 for this about 4 weeks ago, and it worked for a while.
Recently however we're starting to have a similar, but very slightly different, problem.
Our terraform sets up two separate deployments. One started showing this problem in a few days, the other just started doing it this week.
  ~ resource "ec_deployment" "esd" {
      ~ apm_secret_token       = (sensitive value)
      ~ elasticsearch          = {
          ~ cloud_id       = "....hidden...." -> (known after apply)
          ~ config         = {
              + plugins            = (known after apply)
                # (1 unchanged attribute hidden)
            }
          ~ http_endpoint  = "http://....hidden....:9200" -> (known after apply)
          ~ https_endpoint = "https://....hidden....:443" -> (known after apply)
          ~ resource_id    = "....hidden...." -> (known after apply)

This is terraform v1.3.9 and elastic/ec 0.7.0.

I have the same issue

I have a similar issue on Terraform v1.5.2 and ec v0.7.0 but for us, whenever I run terraform apply the diff boils down to:
resource "ec_deployment" "anyline_datalake_deployment" {
      + apm_secret_token       = (sensitive value)
      ~ elasticsearch          = {
          ~ cloud_id       = "cloud_id" -> (known after apply)
          ~ http_endpoint  = "some.cloud.es.io:9200" -> (known after apply)
          ~ https_endpoint = "some.cloud.es.io:443" -> (known after apply)
          ~ resource_id    = "ID" -> (known after apply)
            # (8 unchanged attributes hidden)
        }
        id                     = "id"
        name                   = "name"
        # (7 unchanged attributes hidden)
    }

The ids stay the same between the deployments, so I am not sure what triggers the change in the first place.

We have the same issue. Despite there are no changes in the Terraform configuration, every time we run a plan o apply, we have the following result:
~ resource "ec_deployment" "deployment" {
      + apm_secret_token       = (sensitive value)
      ~ elasticsearch          = {
          ~ cloud_id       = "<cloud_id_value>" -> (known after apply)
          ~ http_endpoint  = "<http_endpoint_value>" -> (known after apply)
          ~ https_endpoint = "<https://endpoint:443>" -> (known after apply)
          ~ resource_id    = "<resource_id_value" -> (known after apply)
            # (11 unchanged attributes hidden)
        }
        id                     = "<id_value>"
        name                   = "<name>"
        # (8 unchanged attributes hidden)
    }

Terraform Version: 1.5.2
Provider Version: 0.7.0

We have the same issue:
Every terraform apply command attempts to make changes. After confirming with yes, it reports that modifications were successful, but when I check the activity center, it doesn't specify what changes were made.
  ~ resource "ec_deployment" "cluster" {       ~ elasticsearch          = {           ~ cloud_id       = "%%%%HIDDEN%%%%" -> (known after apply)           ~ config         = {               + plugins            = (known after apply)                 # (1 unchanged attribute hidden)             }           ~ http_endpoint  = "http://%%%%HIDDEN.us-east-1.aws.found.io:9200" -> (known after apply)           ~ https_endpoint = "https://%%%%HIDDEN.us-east-1.aws.found.io:443" -> (known after apply)           ~ resource_id    = "%%%%HIDDEN%%%%%" -> (known after apply)             # (8 unchanged attributes hidden)         }         id                     = "%%%%HIDDEN%%%%"         name                   = "%%%%HIDDEN%%%%"         # (11 unchanged attributes hidden)     }

same issue

A fix for this was released with 0.8.0 yesterday

Thanks @tobio it solved the error for me.
Terraform v1.4.6
provider registry.terraform.io/elastic/ec v0.8.0

The same for me. Thank you for fixing this issue!


Should events use borrowed or owned values?

It's a bit inconvenient to use borrowed values everywhere, but they are technically more memory-efficient. However, since they're pretty volatile (i.e. probably never appear in smart contract storage), maybe it is better to use owned values, since they'd be easier to read and work with.

Also, I'm currently working on some ideas for NEP-171 (NFT) and the approval extension (which involves modifying the core events). Borrowed values in events are a huge pain. I'm thinking they should be owned.


[style]:  Responsive Developer Profile

What's the style idea?
We need to improve
In card when someone open the profile of developer
Its not responsive
The footer overlap the card
I will make it responsive for mobile view as well
Please assign me this issue
I Forget to add the correct ScreenShots in isssue #600 so I am creating this issue sorry for that.
I am in Gssoc'23
Add screenshots
Add screenshots
Before

After

Code of Conduct

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

could add a good title so that we can discuss this issue?

@priyankarpal  I changed the name of the issue to Responsive Developer Profile

Completed. Thanks for your contributions 🎉 ❤


Fixed keyword order.

This is the preferred order according to ReSharper.

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

Sorry, we don't take PRs for asthetic only changes. I will take a look at your docs PR though.


Remove various synchronisations from cuda API calls, instrument monitor

with nvtx profiler ranges.
@canonizer @trivialfis so far we have been relying on the monitor class with synchronisations in order to estimate the performance of different parts of the gpu_hist algorithm. I have come to realise that the synchronisation itself is a major problem, so I want to rely less on this and use the profiler more.
When built with nvtx the ranges covered by monitor will now clearly show up on the nsight profiler.

@RAMitchell @trivialfis I recall seeing #3799 where NCCL cause NVProf to fail. Was the issue solved?

I haven't even tried profiling the multi-GPU version yet. I will check it before merging.


Is there anyway to get the ITemplateKey inside the cshtml at runtime?

Is there anyway to get the ITemplateKey from inside the CSHTML? For example from the TemplateBase?

I don't think there is.
Normally you know the key of the template when writing the template, why do you need it dynamically?
You could add a string variable to each template with the name, which is not ideal.
I would look into this if you can convince me why we need it.

I'll do my best to convince you ;)
Yes, i know in which template i'm writing the template. However, i would like to not hardcode the paths of my template in my template. For example, when i move the template, normally i would just change the folders i feed into my ResolvePathTemplateManager, but then i would have to change the paths in the templates.
Yes, i could just give a unique key to the template, add all the resources to a unique folder, and then find it based on the unique key in the template itself, but i wanted to do it the ASP.NET way because my coworkers are used to it.

Sooooo... did i convince you? ;)


Ability to add new Userstories

Perhaps this could be accomplished similarly as the tasks are created now but starting with a Feature, then adding child User Stories.
`FE#123 My Feature

This is a new User Story,

This is a task,
This a 2nd task

This is another User Story,

This is another task below a user story
`

Resolved in 0.3.0.
I've used slightly different approach, see README for details.


Add possibility to get dependency from Android Component

Add possibility to get dependency from Android Components without inject it

Hello,
you mean to have the get() eager injection function into Android components.
I push the semantic on the by inject() style lazy properties declaration. But why not unlock the get() function. But I think that most cases can be declared with lazy property injection. The get() function should be used to inject a dependency on a local/short function.

In some case i need dependency to only execute single operation and no need a property. Simple case from Android: main Activity of app check state from preference (that is dependency in Koin) and after this start another screen based on preference value.

This possibility is analogue of method injection from Dagger 2.

Ok

Please check conflicts

I already added the fix - https://github.com/Ekito/koin/commit/789c95fba360057bcd23e6c04045295543de4c91


fix for request body (use postData instead of content)

record response body if recording request body
fix unit testing

Looks good, thanks!
Recording the response body due to saveRequestBody seems a bit misleading though. Maybe we can simply add a saveBody option that controls both - what do you think?

You are right. also added unit test for the response body


If EE is updated with files, no linking will be made

If you use EE and add some new files after m-switch-to-ee, then these files will not be linked to the project. Need to add possibility to re-link EE.

Is possible now with m-switch-to-ee -f


refactor(linter): adding more linter rules

In order to secure the implementations and the code as a whole, this PR reinforces the linter requirements based on the linter file contained in the following eslint-config-standard repo: https://github.com/standard/eslint-config -standard/tree/master.
This PR also fixes the problems that appeared with these new rules as best as possible.
When the problem requires further investigation (only a few cases), the correction of the problem is left for a later PR. In this specific case, this PR simply deactivates the linter for the line in question.
Additionally, this PR also contains an upgrade to the formatting of all the files thanks to the prettier:write command which allows the developer to format all the code files via a single command line.

I don't really agree with this PR, standard introduces too many styling rules which I consider ugly (no semicolon) or make code harder to edit (comma-style). If there are useful rules we can add them individually.
Also FWIW, for typescript projects, eslint-config-standard-with-typescript should be used instead of standard.

@SAPikachu Maybe we can update the.eslintrc.json file to put back the old rules but I think that the PR only bring useful rules (at least from my point of view):

I removed the rule concerning semicolon so we have no error on this this.
Unused variables.
Necessary spacing between functions for a class.
Several redundant imports in the same file
Obligation to return in a findIndex or a map if {}
Global formatting to respect the prettier file.
...

If you don't agree, we can simply close this PR :). But what I propose is that we keep the changes and put the old rules back in the linter if you want (even if the new rules don't seem to disturb that much since there are no errors on CI on the PR). WDT?

Well if we remove the standard extend and rules related to styling (semicolon, comma position, new lines between blocks etc) and fix issues related to TS (like: no-redeclare should be replaced with @typescript-eslint/no-redeclare, see https://typescript-eslint.io/rules/#extension-rules ), I can accept it. :)

@SAPikachu With the last push:

Standard extend is removed
No rule for semicolon
Old rules for comma
lines-between-class-members seems good to be because it helps to air out the code inside a class
Basic typescript specific rules are set:

"@typescript-eslint/explicit-function-return-type": "off",
    "@typescript-eslint/no-unused-vars": ["warn", { "argsIgnorePattern": "^_" }],
    "@typescript-eslint/no-redeclare": ["error"],

If needed, we can complement these rules over time :)

Thanks! Looks mostly good to me. One more suggestion: there are quite a few // eslint-disable-next-line no-redeclare and similar lines added, but they should no longer be needed after the rules are fixed, can you remove these lines? After that I can merge this. :)

Thanks! Looks mostly good to me. One more suggestion: there are quite a few // eslint-disable-next-line no-redeclare and similar lines added, but they should no longer be needed after the rules are fixed, can you remove these lines? After that I can merge this. :)

@SAPikachu Done :)


pine64-rock64: Add support for ROCK64

As mainline U-Boot contains support for the ROCK64, I added support for it to Tow-Boot.
Fixes #151

Hi! :wave:
I know there's no procedure to follow for contributions (yet), so please bear with these few questions:
Can you tell me what was tested?

shared storage [booting the SPI installer from SD from a clean slate would test this]
dedicated storage
SPI installer

cc @Absolucy

Right, there's a few commits that needs to be merged back into development, that's why changing the target branch to development floated them up.

I actually have to admit I'm having some trouble compiling it. Wanted to open the PR so that people watching #151 would be aware it's in progress, and to ask for help.
It's failing with the following config messages:
ERROR: CONFIG_BMP_16BPP is expected to be set to «CONFIG_BMP_16BPP=y», but is not present in config file.
ERROR: CONFIG_BMP_24BPP is expected to be set to «CONFIG_BMP_24BPP=y», but is not present in config file.
ERROR: CONFIG_BMP_32BPP is expected to be set to «CONFIG_BMP_32BPP=y», but is not present in config file.
ERROR: CONFIG_CMD_BMP is expected to be set to «CONFIG_CMD_BMP=y», but is not present in config file.
Warning: CONFIG_SPL_ENV_IS_NOWHERE is expected to be set to «CONFIG_SPL_ENV_IS_NOWHERE=y», but is not present in config file.
ERROR: CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT is expected to be set to «CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y», but is not present in config file.
ERROR: CONFIG_SYS_SPI_U_BOOT_OFFS is expected to be set to «CONFIG_SYS_SPI_U_BOOT_OFFS=0x80000», but is not present in config file.
Warning: CONFIG_TPL_ENV_IS_NOWHERE is expected to be set to «CONFIG_TPL_ENV_IS_NOWHERE=y», but is not present in config file.

I see two general issues in there, for which I need to ask questions:

Does upstream U-Boot support HDMI output on the ROCK64 (or rk3328)?
I assume there's no real support for SPI flash with the ROCK64 yet, given this other somewhat related PR

cc @mirrexagon, I kinda forget what the actual state of what you were doing is.

HDMI output: looks like it's in the device tree for u-boot: https://github.com/u-boot/u-boot/blob/07043055280a91d769ffe5e30d214241bd2e9e78/arch/arm/dts/rk3328.dtsi#L710
SPI flash: I followed https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md a long time ago when I first got my ROCK64. That said, reading what I see in your link suggests that I might be misinformed here.

Regarding SPI flash:

Currently, upstream U-Boot doesn't build SPI images for any Rockchip target, you have to do it manually.
ROCKPro64 SPI images can be built using the method documented upstream, using mkimage, and they work.
ROCK64 SPI boot support is not in upstream currently AFAIK, though I only recently found out the RK3328 boots rksd-format images from SPI, not rkspi format [1], and I haven't retested upstream to see if SPI images built the same way as ROCKPro64 but rksd format work. I suspect that it still needs some changes that Ayufan did on his fork, more on that below.
My patches to get general SPI flash images building in upstream U-Boot [2] are going pretty slowly, and won't have support for the ROCK64 initially (just ROCKPro64 as a known working board).
After that, I'm planning to upstream ROCK64 SPI image support, for which I applied what Ayufan did and tried that and it worked for me - see last commit of https://github.com/mirrexagon/u-boot/tree/rock64-spi which combines Ayufan's changes and my SPI image building changes to build for ROCK64.

[1] I don't remember exactly where I saw it, but maybe one of the patches referenced in a review someone did of my patches notes that the rkspi format that puts data in only the first 2K out of every 4K block thing is to work around a boot ROM bug, so perhaps the bug exists on RK3399 but not RK3328.
[2] https://lists.denx.de/pipermail/u-boot/2022-May/484193.html

The documentation bit was previously in README.rockchip, blame'd to its introduction in 2015:

https://source.denx.de/u-boot/u-boot/-/commit/adfb2bfe50bba29e59fd04a81f0a9bbebdd203ce#5c5212e8f472c00c85d2d14f744d5e0e2b4314de_0_130

Which added support for RK3288.

About HDMI: there's no rk3328 HDMI driver in U-Boot. So this won't be a trivial thing to get going.
I don't really know the platform yet, but if the subsystems on the 3328 are close enough to 3399, it might be possible to handle.

Note that I'm getting the same build failure as @moosingin3space was, and I can't really test this as a result.

@moosingin3space I went ahead and:

split your commit in three distinct commits
finished Rock64 support as co-author
made some necessary changes around the rockchip builder

I took the liberty of force-pushing on this PR branch, your changes (except for the rock64 commit) are untouched. The rock64 commit only has relevant additions.
If you have any concern with the changes, don't hesitate to ask.

What works

Tow-Boot starts from SD
Tow-Boot starts from SPI
Tow-Boot can be installed from the installer (using the serial console)

What is untested

Booting an OS from SD
Booting an OS from eMMC

What doesn't work

USB mass storage (on any of the three ports)

Have you already moved the U-Boot environment to SPI flash? I think it's still on SD/MMC upstream, and I didn't see a change for that in this PR.

Have you already moved the U-Boot environment to SPI flash? I think it's still on SD/MMC upstream, and I didn't see a change for that in this PR.

Good question, it's already all handled at a level prior to board-specific configurations:

https://github.com/Tow-Boot/Tow-Boot/blob/797acbfb18ef575f9028bb3b41cc8c9685af8345/modules/tow-boot/config.nix#L113-L131

So it's handled out of band since this is a place where Tow-Boot differs in an opinionated manner compared to U-Boot.

@samueldr Thank you very much! I will give this a test on my Rock64.

First report: I have successfully flashed Tow-Boot to my Rock64's SPI. After the flash, I removed my microSD card. It then attempts to boot from SD, then USB, then PXE. After timing out, it displays a menu, and I selected Firmware Console, where I was presented with a typical U-Boot console.
Next thing to try: a Fedora AArch64 generic image on the SD card.

Initial Fedora report:

I downloaded the bootable ISO image Fedora-Server-netinst-aarch64-36-1.5.iso. This did not work -- the USB bus reported:Bus usb@ff5c0000: USB EHCI 1.00
Bus usb@ff5d0000: USB OHCI 1.0
Bus usb@ff580000: USB DWC2
scanning bus usb@ff5c0000 for devices... 1 USB Device(s) found
scanning bus usb@ff5d0000 for devices... 1 USB Device(s) found
scanning bus usb@ff580000 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found

Looks like USB doesn't work. Let's try something else.
I then downloaded the raw filesystem image Fedora-Server-36-1.5.aarch64.raw.xz. This image contains an EFI system partition with Grub. I used dd to write the image to the SD card, then selected "Boot from SD Card" in Tow-Boot's serial menu. After a while, it launched Grub, and then a few minutes later, I was prompted on serial to create a user. After that, I was able to log into the Cockpit UI. I'll call this one a success!

Did not test PXE boot -- need to see if my network equipment can pass the requisite DHCP options for PXE boot.
I'm going to mark this PR as ready. Thank you everyone!

Last update for now: looks like Linux doesn't properly enumerate the USB device either -- when I try to plug in the above USB stick and run lsblk, it doesn't show up.

The fact that Linux doesn't enumerate USB is odd. Though it depends on the exact setup.
Though USB not working at this moment with the Rock64 is somewhat expected, as observed on my end too.

Coming soon:
scanning bus usb@ff580000 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found

I get what is going on, and there is a solution. Though the USB 3 port can't be used (?)
TLDR, the main issue is that there's no power to the USB ports. Using a USB power monitor, the power monitor doesn't even turn on. With the appropriate changes it turns on.

I've looked quickly at HDMI, and reading the Linux drivers, it differs too much from the existing RK3288 and RK3399 implementations to be a trivial thing to implement.
So for the time being, it'll have to be used through serial :/.

TLDR, the main issue is that there's no power to the USB ports. Using a USB power monitor, the power monitor doesn't even turn on. With the appropriate changes it turns on.

Okay, that's pretty interesting. With this fix, I was able to boot the Fedora Server 36 netinstall image when plugged into one of the USB 2 ports. USB 3, indeed, does not work, but my drive is powered on this time. Looks like it's a bug in the u-boot XHCI driver.
Thankfully, it appears as though someone has already found a solution to the Linux bug: https://artemis.sh/2022/05/16/everfrees-armferno.html (mentioned under the Device Trees header, looks like it's slated for 5.19). Based on hearing this, I might just build a minimal image with Buildroot or Yocto that uses Linux 5.19 for the sake of testing USB on this platform.

Aside, it appears as though JTAG headers are exposed on the Rock64: https://crwulff.blogspot.com/p/rock64.html
This could help significantly with debugging some of these drivers.

The underlying issue is a bit more subtle than implied in that post.
The problem is that the innate FDT (the built-in device tree) is built for U-Boot, with quirks added. There is a quirk added by U-Boot disabling the always-on USB power. This is what the patch from ayufan works around within U-Boot.
So a workaround is to load the device tree from a mainline Linux dtbs folder for the rock64 before booting Linux. How to do so differs depending on the boot method used. Some methods are documented in distro.rst..
A solution would be to implement a generic method of "unquirking" a for-U-Boot device tree before booting an operating system. Doing so would be pretty much equivalent to loading the mainline Linux device trees as they are regularly synced in U-Boot with the mainline Linux trees.

I may be dumb, but I can't seem to get any serial output?
Tried flashing both spi.installer.img and shared.disk-image.img to a microSD. ROCK64 turns on, but no output over UART. 112500 baud rate and all.

It's 115200, if that wasn't a typo. Though it's plausible that length can be an issue for UART, too. Also check if RX/TX weren't swapped, it's IMO always weird with the labeling.

Thanks for the explanation. I have a number of questions, as my experience with U-Boot isn't that extensive.

The problem is that the innate FDT (the built-in device tree) is build for U-Boot, with quirks added.

So basically, U-Boot loads a device tree that has certain quirks, ostensibly to account for differences between U-Boot and Linux drivers, and then Linux loads the same one from some specified address?

So a workaround is to load the device tree from a mainline Linux dtbs folder for the rock64 before booting Linux. How to do so differs depending on the boot method used. Some methods are documented in distro.rst.

To clarify: in the case where I have a UEFI-booting distribution image (i.e. Fedora), this implies that U-boot must load the device tree? I was under the impression that in the case of something like the Fedora AArch64 generic image, GRUB (the bootloader it ships with) would handle booting Linux with the mainline device tree.
Perhaps I just need to build a minimal distro with Yocto (or even Nix -- I noticed your work on linux-3ds.nix, that's really cool :smile:) and drop into an interactive console to boot it, just so I can see how that's supposed to work.

A solution would be to implement a generic method of "unquirking" a for-U-Boot device tree before booting an operating system. Doing so would be pretty much equivalent to loading the mainline Linux device trees as they are regularly synced in U-Boot with the mainline Linux trees. This would be helpful to keep the concerns separate about the U-Boot-specific device tree, and the generic innate device tree.

This would be something done upstream, I assume. Would it basically result in the same effect (loading the mainline device tree when booting Linux)? Or would it move the responsibility into the OS?

Those are "heavy" questions, and this will derail the discussion a bit, and possibly exponentially grow. Though let's try and answer them. Some of them will stretch my verified knowledge and might slip into assumptions.
A lot of the answers will be about my opinionated ideals that are currently mostly fiction in the ecosystem.

The problem is that the innate FDT (the built-in device tree) is build for U-Boot, with quirks added.

So basically, U-Boot loads a device tree that has certain quirks, ostensibly to account for differences between U-Boot and Linux drivers, and then Linux loads the same one from some specified address?

Yeah~ish. Here U-Boot does the loading, and tells the OS (Linux here) where the FDT is in memory. When there is no "loading" done, e.g. with UEFI by default, U-Boot will re-use what I call the "innate" FDT, the one that U-Boot was built with.
We'll see that Linux completely absolving itself from the task of loading the correct dtb file is a recurring theme, and a problem.

So a workaround is to load the device tree from a mainline Linux dtbs folder for the rock64 before booting Linux. How to do so differs depending on the boot method used. Some methods are documented in distro.rst.

To clarify: in the case where I have a UEFI-booting distribution image (i.e. Fedora), this implies that U-boot must load the device tree? I was under the impression that in the case of something like the Fedora AArch64 generic image, GRUB (the bootloader it ships with) would handle booting Linux with the mainline device tree.

Any component before the OS can load the FDT in memory. Though there is a severe dysfunction in that there is no way to know which dtb file to load. So when targeting generic boot, you can't get GRUB to e.g. load the Pinebook Pro dtb on the Pinebook Pro, GRUB (and pretty much all tools except U-Boot) have no way to ask "who am I loading this for?".
I have not verified what the actual Fedora iso does, I suspect either it does nothing special, or it adds the "ESP:/dtb" folder with the kernel-built device tree binaries. The latter is a sort of workaround that U-Boot people implemented to allow a "more correct" dtb file to be generally loaded. This is possible since it's U-Boot that will load the "correct" dtb file before starting the EFI program.
So, how does U-Boot does it? "Heuristics"!
Generally speaking, the platform name is either entirely hardcoded, or there is a small detection routine in a board-specific file that will distinguish between few compatible platforms (e.g. Pinephone A64).

[...]

A solution would be to implement a generic method of "unquirking" a for-U-Boot device tree before booting an operating system. Doing so would be pretty much equivalent to loading the mainline Linux device trees as they are regularly synced in U-Boot with the mainline Linux trees. This would be helpful to keep the concerns separate about the U-Boot-specific device tree, and the generic innate device tree.

This would be something done upstream, I assume. Would it basically result in the same effect (loading the mainline device tree when booting Linux)?

Development could happen here, but it should probably be coordinated with upstream so that it is acceptable to them.
The effect wouldn't exactly be "loading the mainline device tree when booting Linux", but it sure would look similar to it. The effect would be that we'd undo the "quirky" changes U-Boot applies (e.g. see rk3328-rock64-u-boot.dtsi). In turn, since U-Boot frequently syncs the device tree definitions with mainline Linux, it would in practice give the same ballpark result you were describing.

Or would it move the responsibility into the OS?

You hit the nail on the head. We're now diving into my opinion on the subject matter.
I think there is one deep flaw that needs to be solved with the trifecta Device Tree, Linux, Generic Boot: the kernel wants its own device tree representations, but does absolutely nothing to make it easy or possible. Everything has been authored with an extremely embedded mindset, where the platform is tightly vertically integrated.
I might be missing some things, but basically I think that dtb files shouldn't be handled by the bootloader stages, since they have no way to know which file to load (or a protocol devised to be implemented by the bootloaders).
One way I've thought up to handle this would be to bundle all dtb files from a kernel build in a cpio archive, and load it with the kernel "before" the initramfs.
The kernel in its earliest init would look at the current "facts" available about the platform, and somehow select the right dtb file. That somehow is load bearing. Note that the same exact system could be used for ACPI platforms to implement quirks with an "overlay" instead of peppering the whole tree with dmi_*_match quirks (or maybe Linux should treat DT equal to ACPI, and use dt_*_match to apply quirks in drivers instead of "fixing" the device tree).
What facts are there? I don't exactly know, but I have a few in mind. First, a new DT property could be added to short-circuit facts-checking e.g. /linux,dtbname, when present the kernel knows this is the "truth" and loads that file. That won't help for existing platforms, or platforms that don't implement that extension to DT. In these cases, looking at /compatible should and /model and fudge around hashes could be done to look up which file to load. But that isn't enough as many platforms ship with inadequate names here. For these it might be best to look at "unique enough" properties e.g. /compatible × &panel/compatible, add a couple other data point that uniquely identify the platform and there you have it.
With such a scheme, you would resolve I believe all Linux-side pains with ARM and Generic Boot. It would be possible to implement the same scheme in a bootloader step, the same strategy is used for WoA laptops [citation needed], but the solution needs to be applied as close as possible to the kernel or else it continues being an issue to any platforms not using the special solution. Another issue with a bootloader-y step is that for OS with generations like NixOS, you might face an issue where you need to first load the "correct" dtb file, but the "correct" dtb file will vary depending on which kernel/system generation you boot next. This would also affect other similar strategies, like I think SUSE does with Snapper.

I moved this from the response, as I don't know how to interpret this:

Perhaps I just need to build a minimal distro with Yocto (or even Nix -- I noticed your work on linux-3ds.nix, that's really cool smile) and drop into an interactive console to boot it, just so I can see how that's supposed to work.

This seems unrelated to the FDT/boot questions. Or do you mean that you want to know how to manually boot an OS using the U-Boot console? It won't be as helpful as you'd hope if you want to boot with EFI, as you'd basically load the EFI program, and run it. And otherwise the boot process is different enough when booted through U-Boot native methods that it won't exactly map to EFI boot semantics.
Note that the knowledge learned with the linux-3ds.nix shenanigans is part of celun, which you can see a use of with the embedded Linux OS build for the touch installer for Tow-Boot.

Sorry for the long rambling! If anything needs to be discussed still... I don't know where it should be... But there's the matrix room (#Tow-Boot:matrix.org), where it might be easier to bounce smaller bite-sized questions/answers instead of huge essays :).

Thank you for the incredibly detailed response, you are teaching me quite a bit about the way that these SBCs work. My experience in this area has been heavily focused on the embedded Linux side, after U-Boot loads an ITB-formatted image with kernel, initramfs, and device tree. That's a very... embedded systems way to do it, versus the generic boot mechanism that you're describing, and that Tow-Boot aims to provide.

Bringing this conversation back to this specific PR's goal, bringing up Tow-Boot on a ROCK64, and the questions regarding booting a Fedora Server ISO, I opened the ISO with guestfish and managed to find this:
><fs> cat /EFI/BOOT/grub.cfg
set default="1"

function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2

set timeout=60
### END /etc/grub.d/00_header ###

search --no-floppy --set=root -l 'Fedora-S-dvd-aarch64-36'

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Install Fedora 36' --class red --class gnu-linux --class gnu --class os {
	linux /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-dvd-aarch64-36 ro
	initrd /images/pxeboot/initrd.img
}
menuentry 'Test this media & install Fedora 36' --class red --class gnu-linux --class gnu --class os {
	linux /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-dvd-aarch64-36 rd.live.check
	initrd /images/pxeboot/initrd.img
}
submenu 'Troubleshooting -->' {
	menuentry 'Install Fedora 36 in basic graphics mode' --class red --class gnu-linux --class gnu --class os {
		linux /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-dvd-aarch64-36 nomodeset
		initrd /images/pxeboot/initrd.img
	}
	menuentry 'Rescue a Fedora system' --class red --class gnu-linux --class gnu --class os {
		linux /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-dvd-aarch64-36 inst.rescue
		initrd /images/pxeboot/initrd.img
	}
}

I can't tell, from this, how it decides what device tree to load. Decided to look at the boot loader for the raw image:
><fs> cat /boot/loader/entries/e18134ba4d124da581bbd0eb9114b13f-5.17.5-300.fc36.aarch64.conf
title Fedora Linux (5.17.5-300.fc36.aarch64) 36 (Server Edition)
version 5.17.5-300.fc36.aarch64
linux /vmlinuz-5.17.5-300.fc36.aarch64
initrd /initramfs-5.17.5-300.fc36.aarch64.img
options root=/dev/mapper/fedora_fedora-root ro rd.lvm.lv=fedora_fedora/root rhgb quiet
grub_users $grub_users
grub_arg --unrestricted
grub_class fedora

This doesn't appear to specify a device tree either. It looks to me as if Fedora, when booted with UEFI on AArch64, expects to be able to find ACPI tables. There's definitely a device tree binary located on the boot partition at /boot/dtb/rockchip/rk3328-rock64.dtb, but it doesn't look like Grub passes that in.
So I guess the next question is: what's next for this PR?

So I guess the next question is: what's next for this PR?

I'm not sure. I don't like the fact that the innate FDT is "wrong" as far as Linux is concerned, but it's not like it's something that's caused by changes from Tow-Boot. So I should ignore that detail since it's the same with upstream.
I don't like that HDMI out doesn't work... but same story, upstream problem.
So really, it's probably as ready as can be.

[cut down fedora aarch64 exposition]
This doesn't appear to specify a device tree either. It looks to me as if Fedora, when booted with UEFI on AArch64, expects to be able to find ACPI tables. There's definitely a device tree binary located on the boot partition at /boot/dtb/rockchip/rk3328-rock64.dtb, but it doesn't look like Grub passes that in.

Fedora AFAIK on AArch64 "expects" ACPI tables just as much as other "standards-based boot" distros do, really DT is fine too.
Is the boot partition you're speaking of the ESP? If so, U-Boot itself (and thus Tow-Boot) should load the dtb file according to its heuristics before starting the UEFI program.

https://source.denx.de/u-boot/u-boot/-/blob/v2022.01/include/config_distro_bootcmd.h#L150-164

There are no mechanisms available after U-Boot relinquishes control to determine the "correct" dtb file name to load. So any UEFI program loading a dtb file would need to hardcode the platform, so it's not an option for generic boot images (and should be seen as a workaround for device-specific systems).

Is the boot partition you're speaking of the ESP? If so, U-Boot itself (and thus Tow-Boot) should load the dtb file according to its heuristics before starting the UEFI program.

It is not - the ESP contains grub with a grub config that mounts a different (XFS) partition. That XFS partition contains the dtb. I am not sure why it doesn't just use the ESP for storing all the boot resources.
Does this imply that if I were booting a distribution that placed the dtbs on the ESP, U-Boot should load Linux's device tree according to heuristics?

Yes, this is precisely what the code aims to do.
Note that the dtb folder (or dtb/current folder) has to be structured like the dtb folder from a Linux kernel build, so it will look something like ESP:/dtb/rockchip/rk3328-[...].dtb.

:x: This can't be merged as-is.
A discussion with @mirrexagon floated up an issue I had forgotten about: there are variants that needs slower RAM init, or else the board might exhibit issues.
See this discussion:

https://github.com/NixOS/nixpkgs/pull/145506

So this will require fishing-up the proprietary ram training bits from other WIP branches.

Hi, sorry for the silence. I will have to look through ayufan's commits to see if there are any patches relating to RAM init across variants, or even detection of the variants with this requirement.

Moving this in 007 to expedite 006 with finished work.
Also noting that downstream-upstream there are further changes related to RAM init that we might want to look at

https://github.com/NixOS/nixpkgs/pull/191538

Namely, I wasn't aware of it for lpddr3, mainline U-Boot already has multiple blobs for RAM init with different speeds available. I assumed there wasn't from experience with #54 where it's not the case for lpddr4.
So I want to take proper care to verify this.
We'll also need to figure out how we handle differing RAM init...
Do we build multiple builds? For now I guess we can build with the single slower RAM init and push that question as something to be answered later. Maybe an "applet" within the future configuration menu that can be used to replace the blob in-situ? Though that would be hard and prone to errors.

We'll also need to figure out how we handle differing RAM init...

Is there documentation from Pine64 (or Rockchip) about how the different variants require different raminit?

At this time, what are the remaining issues before this is in an acceptable state?
From what I understood:

SPI does not work (yet? https://github.com/mirrexagon/u-boot/tree/rock64-spi isn't merged) - comment
there needs to be a way to do RAM training for multiple board variants - comment
HDMI is in the dt, but it's missing the actual driver in u-boot - comment

Looking at https://wiki.pine64.org/wiki/ROCK64#Information,_Schematics_and_Certifications, I can see two board variants (2.0 and 3.0) and 3 RAM variants (Hynix, Samsung, Spectek)
I have a ROCK64 2GB, but I'm not sure which variant it is; is there anything I can help with?


[SECURITY/CVE/CRITICAL] Meshcentral is injected during docker build run

What happened?
The command devbox generate dockerfile generates a docker file that pulls dangerous/malicious dependencies (meshcentral 1.1.6 package, ~500MB) during the docker build process (e.g. docker build -t devbox-empty-test2 .).
How to reproduce:
devbox init
devbox add vim # added random package, because devbox throws a error if devbox.lock does not exist yet..
devbox rm vim
devbox generate dockerfile -f
docker build -t devbox-empty-test2 .

Looking at the Dockerfile (cat Dockerfile) reveals:
FROM jetpackio/devbox:latest

# Installing your devbox project
WORKDIR /code
USER root:root
RUN mkdir -p /code && chown ${DEVBOX_USER}:${DEVBOX_USER} /code
USER ${DEVBOX_USER}:${DEVBOX_USER}
COPY --chown=${DEVBOX_USER}:${DEVBOX_USER} devbox.json devbox.json
COPY --chown=${DEVBOX_USER}:${DEVBOX_USER} devbox.lock devbox.lock

RUN devbox run -- echo "Installed Packages."

CMD ["devbox", "shell"]

During the execution of RUN /bin/sh -c devbox run -- echo "Installed Packages." # buildkit the dangerous dependencies are pulled through the meshcentral 1.1.6 package. This is very disturbing, also because the package does not make any sense to exist in the first place on a empty Project.
Inspect the generated docker image by using docker-desktop (or a suitable vuln/dep scanning tool):

Just the meshcentral 1.1.6 package alone has 4 CVEs. 3 with high severity and 1 with critical severity. The CVEs are:
CVE-2023-51837
CVE-2024-26135
CVE-2023-51842
CVE-2023-51838
Steps to reproduce
devbox init
devbox add vim # just added random package, because devbox throws a error that devbox.lock does not exist yet..
devbox rm vim
devbox generate dockerfile -f
docker build -t devbox-empty-test2 .

Command
No response
devbox.json
{
  "$schema":  "https://raw.githubusercontent.com/jetify-com/devbox/0.13.7/.schema/devbox.schema.json",
  "packages": [],
  "shell": {
    "init_hook": [
      "echo 'Welcome to devbox!' > /dev/null"
    ],
    "scripts": {
      "test": [
        "echo \"Error: no test specified\" && exit 1"
      ]
    }
  }
}

Devbox version
0.13.7
Nix version
nix (Nix) 2.24.7
What system does this bug occur on?
macOS (Apple Silicon)
Debug logs
macOS 14.6.1 (Apple M1 Pro)

Thanks for the report. We're looking into it.

@iocron thanks for reporting this issue, I looked into it quite in detail. The CVE is correct but Meshcentral is not injected at all. In fact, there is no Meshcentral binary in a built dockerfile. I search for it in the entire filesystem in a built container.
There are 2 places where meshcentral exists:
devbox@f85313a7724c:/code$ find / -type f -name "*meshcentral*" 2>/dev/null

/nix/store/5kli0hmba13hczv8gni1gvzi4ir8w21b-nixpkgs/nixpkgs-25.05pre720687.5a48e3c2e435/nixos/modules/services/admin/meshcentral.nix

/nix/store/j0jlb33bm31w347w43051hbffgh616jr-source/nixos/modules/services/admin/meshcentral.nix

The first path is part of the nixpkgs package itself that contains a few .nix files as services. meshcentral.nix is there to allow remote desktop capability to nixOS. The second file is the source for those services.
That said, if you add RUN nix-garbage-collect -d & RUN nix-store --optimise after devbox run, it will remove these files and the scanner tool won't flag them as critical.
These 2 lines, remove unused packages and files in nix store and deduplicate installed packages.
RUN devbox run -- echo "Installed Packages."

RUN nix-collect-garbage -d
RUN nix-store --optimise

@mohsenari Thats incorrect. There are other multiple places, and the binary does exist, let me explain it below shortly (due to restricted time I only checked a small portion):

At first sight there are artifacts of a meshcentral node/yarn installation and obfuscation at multiple places, not just a binary (sudo grep -rin meshcentral /nix/store can be one of multiple starting points)
/nix/store/2ikz1s663gfg2sxg1yrv4wzjn908axg2-nixexprs.tar.xz has the binary meshcentral (and some other dependencies and IaC tools like pgadmin, procs, pulumi, google cloud sdk, etc.)
there are some obfuscations going on anyway (i doubt you will find all indices easily, unraveling/resolving the obfuscation might take a long time). Also there might be some hooking going on (e.g. some proc or static trigger unpacks and uses the file only during a specific interaction)
Meshcentral is not part of any nix/nixos default, also bloats the image massively, so why is it there in the first place?
"meshcentral.nix is there to allow remote desktop capability to nixOS" => Why would anyone ever want to allow a rdp tool/service like meshcentral inside a default docker image?
Due to all points mentioned, I do highly recommend to remove the injected packages from the default docker generation. A garbage collection like nix-collect-garbage -d && nix-store --optimise does not solve the problem / root cause

@iocron I went through and looked at the Docker Desktop results, and this seem like a false-positive that's detecting the package.json file for meshcentral. The exact location I got was /nix/store/j0jlb33bm31w347w43051hbffgh616jr-source/pkgs/tools/admin/meshcentral/package.json.
nixpkgs sometimes includes files like this so it can auto-generate parts of the build process for packages. In this case, it uses the package.json to download/hash dependencies of meshcentral and update the package.
To be clear, none of this is actually happening and meshcentral isn't actually being built unless you install meshcentral with Devbox or Nix. It's just in the container because Nix packages are all defined in the same git repo.
I looked in the paths you mentioned (including in /nix/store/2ikz1s663gfg2sxg1yrv4wzjn908axg2-nixexprs.tar.xz) and couldn't find an actual binary anywhere. If there are specific paths you think we should take a look at, let us know.


How to listen by local ScreamReader?

I installed Scream driver and started ScreamReader. Default device is hardware soundcard. I expexted listen sound when I press test button in properites tab of Scream device. But I can not hear anything. When I configure Scream device to unicast to another local PC, I hear test sound.
I have router with OpenWRT. How to configure my system?

Hi @3bagorion33 can you clarify what's your setup?
It doesn't make much sense to install both Scream driver and ScreamReader on the same windows machine but maybe you are using a VM ?

Probably because scream driver binds to port 4010
netstat -na

  UDP    <IP_ADDRESS>:4010           *:*

Anyway I can't get netcat to listen on my local machine for troubleshooting
This looks like it's listening to 4010 though. scream driver transmits from source 4010 to destination 4010.
Is this required by Windows sockets?
I would like to try scream using localhost so I can try with scream receiver/jack(?) pulseaudio in Cygwin.
Use cases would include sound with X or unix/Cygwin ports.
I'm looking for an open source  way to route windows sound to Airplay/Chromecast which I can do with a remote forked-daapd server
Maybe there's another free Windows driver that already does this?


Use md5 of the content in ETag header

S3 client by default expects ETag header to be md5 of the content. So far, clients have been using configs to disable md5 validation.
This change populates md5 checksum in the ETag header for regular uploads. For multipart uploads, it involves more complex changes and will be done later

Codecov Report
Attention: Patch coverage is 0% with 15 lines in your changes missing coverage. Please review.

Project coverage is 16.00%. Comparing base (52ba813) to head (c475404).
Report is 134 commits behind head on master.

Files with missing lines
Patch %
Lines

...ava/com/github/ambry/frontend/s3/S3PutHandler.java
0.00%
15 Missing :warning:

:exclamation:  There is a different number of reports uploaded between BASE (52ba813) and HEAD (c475404). Click for more details.
HEAD has 2 uploads less than BASE

Flag
BASE (52ba813)
HEAD (c475404)

3
1

Additional details and impacted files
@@              Coverage Diff              @@
##             master    #2933       +/-   ##
=============================================
- Coverage     64.24%   16.00%   -48.25%
+ Complexity    10398     3053     -7345
=============================================
  Files           840      865       +25
  Lines         71755    73680     +1925
  Branches       8611     8864      +253
=============================================
- Hits          46099    11790    -34309
- Misses        23004    61031    +38027
+ Partials       2652      859     -1793

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


⚠ Carbubu has degraded performance

In 3633982, Carbubu (https://carbubu.fr) experienced degraded performance:

HTTP code: 200
Response time: 3247 ms

Resolved: Carbubu performance has improved in 9ac0a26 after 6 minutes.


Add AddDataAnnotationsLocalization parameterless overload.

The IMvcBuilder extension methods already had this overload, just adding it to IMvcCoreBuilder.

#3517

/cc @rynowak

:shipit:


App manager initializes fully

Tidied up the initialization behavior, accounted for some fixable issues, and threw some more logging back in.

Surprisingly grueling, but feels worth it.
Addresses a check in #17


IE - incompatibility with new CustomEvent

Can you please add native support of CustomEvent functions for IE, without using approach with polyfills?

This was a conscious decision as not all consumers of this library need to support old versions of IE

@jshjohnson In order to support IE 9/10/11 one can use following syntax for custom events, no polyfills needed:
var event = document.createEvent('CustomEvent');
event.initCustomEvent(...);

See https://caniuse.com/#search=CustomEvent
If you're interested, let me know and I'll prepare a pull request.

@jshjohnson WDYT?


Adds 'TEST of KLASS3-SK 2016' certificate and organization certs support

Added TEST of KLASS3-SK 2016 to trusted CA list;
Uses Common Name in case of an organization certificate instead of first and last name.

Signed-off-by: Erkki Arus<EMAIL_ADDRESS>

Abandoning for a while.


Warn about F0467 - Encap already in use

Warn about encap in use so that any conflicting config can be deleted before the upgrade. This might prevent the wrong vlan from being pushed to an interface after an upgrade.

694178406 - BCBS case that went around the world for 3 days before I was pulled in. It was a case where a service graph broke after an upgrade. It was caused by another vlan being pushed instead of the shadow epg vlan.

# Test 1: No fault raised
benjwils@a-apic1:techsupport> python aci-preupgrade-validation-script-r1.py
[Check 21/44] Encap Already In Use (F0467 encap-already-in-use)...                                                                    PASS

# Test 2: One fault raised
admin@fab5-apic1:techsupport> python aci-preupgrade-validation-script-r1.py
[Check 21/44] Encap Already In Use (F0467 encap-already-in-use)...                                                FAIL - OUTAGE WARNING!!
  Fault  DN of Faulted EPG              In Use by EPG                    Node  Overlapping Encap(s)  Recommended Action
  -----  -----------------              -------------                    ----  --------------------  ------------------
  F0467  uni/tn-bw/ap-mcast/epg-mcast1  uni/tn-bw/ap-physical/epg-phys3  104   vlan-101              Resolve the conflict by removing the faulted configuration for the overlapping encap(s)

# Test 3: Multiple faults raised; same EPG pair but different nodes
admin@fab5-apic1:techsupport> python aci-preupgrade-validation-script-r1.py
[Check 21/44] Encap Already In Use (F0467 encap-already-in-use)...                                                 FAIL - OUTAGE WARNING!!
  Fault  DN of Faulted EPG                In Use by EPG                    Node  Overlapping Encap(s)  Recommended Action
  -----  -----------------                -------------                    ----  --------------------  ------------------
  F0467  uni/tn-bw/ap-mcast/epg-mcast1    uni/tn-bw/ap-physical/epg-phys3  104   vlan-101              Resolve the conflict by removing the faulted configuration for the overlapping encap(s)
  F0467  uni/tn-bw/ap-physical/epg-phys2  uni/tn-bw/ap-physical/epg-phys1  101   vlan-302              Resolve the conflict by removing the faulted configuration for the overlapping encap(s)
  F0467  uni/tn-bw/ap-physical/epg-phys2  uni/tn-bw/ap-physical/epg-phys1  102   vlan-302              Resolve the conflict by removing the faulted configuration for the overlapping encap(s)

< 16:04:51 benjwils ~/ApicAPI/ACI-Pre-Upgrade-Validation-Script/ACI-Pre-Upgrade-Validation-Script> $ pytest tests/test_logic.py --verbose
=========================================================================================================================================================== test session starts ===========================================================================================================================================================
platform darwin -- Python 2.7.15, pytest-4.6.11, py-1.11.0, pluggy-0.13.1 -- /Users/benjwils/.virtualenvs/ApicAPI-new/bin/python2.7
cachedir: .pytest_cache
rootdir: /Users/benjwils/ApicAPI/ACI-Pre-Upgrade-Validation-Script/ACI-Pre-Upgrade-Validation-Script
collected 23 items

tests/test_logic.py::test_aciversion PASSED                                                                                [  4%]
tests/test_logic.py::test_get_vpc_nodes PASSED                                                                                [  8%]
tests/test_logic.py::test_defect_eventmgr_db[3.2(5e)-4.2(4r)-PASS] PASSED                                                                                [ 13%]
tests/test_logic.py::test_defect_eventmgr_db[3.2(10g)-4.2(4r)-PASS] PASSED                                                                                [ 17%]
tests/test_logic.py::test_defect_eventmgr_db[4.1(2a)-4.2(7a)-PASS] PASSED                                                                                [ 21%]
tests/test_logic.py::test_defect_eventmgr_db[3.2(4a)-5.2(2a)-FAIL - UPGRADE FAILURE!!] PASSED                                                                                [ 26%]
tests/test_logic.py::test_defect_eventmgr_db[4.0(1a)-5.2(3a)-FAIL - UPGRADE FAILURE!!] PASSED                                                                                [ 30%]
tests/test_logic.py::test_apic_ca_cert_validation[4.2(5e)-5.2(6e)-POS_certreq.txt-FAIL - OUTAGE WARNING!!] PASSED                                                                                [ 34%]
tests/test_logic.py::test_apic_ca_cert_validation[4.2(4a)-5.2(2a)-NEG_certreq.txt-PASS] PASSED                                                                                [ 39%]
tests/test_logic.py::test_vpc_paired_switches_check PASSED                                                                                [ 43%]
tests/test_logic.py::test_llfc_susceptibility_check PASSED                                                                                [ 47%]
tests/test_logic.py::test_pos_telemetryStatsServerP_object_check PASSED                                                                                [ 52%]
tests/test_logic.py::test_neg_telemetryStatsServerP_object_check PASSED                                                                                [ 56%]
tests/test_logic.py::test_pos_isis_redis_metric_mpod_msite_check PASSED                                                                                [ 60%]
tests/test_logic.py::test_neg_isis_redis_metric_mpod_msite_check PASSED                                                                                [ 65%]
tests/test_logic.py::test_missing_isis_redis_metric_mpod_msite_check PASSED                                                                                [ 69%]
tests/test_logic.py::test_switch_bootflash_usage_check_new PASSED                                                                                [ 73%]
tests/test_logic.py::test_contract_22_defect_check PASSED                                                                                [ 78%]
tests/test_logic.py::test_pos_internal_vlanpool_check PASSED                                                                                [ 82%]
tests/test_logic.py::test_neg_internal_vlanpool_check PASSED                                                                                [ 86%]
tests/test_logic.py::test_pos_encap_already_in_use_check PASSED                                                                                [ 91%]
tests/test_logic.py::test_neg_encap_already_in_use_check PASSED                                                                                [ 95%]
tests/test_logic.py::test_bgp_golf_route_target_type_check PASSED                                                                                [100%]

======================================================================================================================================================== 23 passed in 0.25 seconds ========================================================================================================================================================


WIP: Patch libpng usage to eliminate known vulnerabilities

Related to #534, this PR focuses on the modifications to Android and keeps the changes as simple as possible (the changes made should be consistent and use CMake to introduce libpng to increase flexibility for future changes, with the intention of splitting it into two steps, such as adding ASM support later). Other platforms only modify the source code version and maintain the original integration method. It has been compiled and tested successfully in Android with CMake and Emscripten with gmake, but cannot be tested properly in Android with Visual Studio and Emscripten with Visual Studio. Relevant personnel are requested to check the operation status. Linux and NXS should not be affected, please also check.
Analysis
By searching for references to the png.h header file, it is found that:

Android uses Native libpng to read "*.png" files through platform/android/ndk/AndroidImageDecoder.cpp, and if that fails, it will use Java decoding (note that during testing, fallback to Java implementation should be avoided).
Emscripten/Linux/NXS uses libpng to read and write png files through platform/shared/Rtt_BitmapUtils.cpp.
The third-party library freetype also has code referencing "png.h" but it is not actually used because the FT_CONFIG_OPTION_USE_PNG definition is not turned on by default.

By analyzing the compilation scripts for each platform, it is found that the source code version, compilation and linking are as follows:

Android uses external/lpng1256, which is the same as sourceforge.net lpng1256.zip, except that the line breaks may be inconsistent. For GitHub Action, Android uses gradle script to directly refer to libpng source code files through CMake, and does not use the CMake script provided by libpng. The Visual Studio project file is another toolchain and cannot be compiled successfully. The Visual Studio project platform points to Tegra-Android, and it is suspected whether it can be used normally.
Emscripten uses external/libpng1243b01, which is the same as sourceforge.net libpng-1.2.43beta01.tar.gz. It is not recommended for use beta in production environments, and it has NXS's predefined modifications (which have also been moved to the git module and annotated), and the predefined have no impact on Android. For GitHub Action, libpng source code is referred to through gmake, and the CMake script provided by libpng is not used. There are also additional Visual Studio project files, but the compilation fails and there is no corresponding processing for CopyResource.sh, which used to create resource.car on Android or resource.corona-archive on iOS, and it is suspected that it is incomplete.
Linux uses find_package() to determine the version installed, so this PR modification of the source code version does not affect Linux (maybe NXS also uses Linux scripts? Or maybe it uses source code integration, which needs to be tested. I do not have NXS or developer access, so I hope someone can test it).

Modification
In order to reduce redundancy, version 1.6.39 is used uniformly. The open source license of libpng 1.6.39 is compatible with Solar2D, and cve-bin-tool no longer detects related vulnerabilities.
Except for NXS header file definition changes, lpng1256 or libpng1243b01, both are version 1.2. The main changes from version 1.2 to 1.6.39 are:

Two useless c files were deleted Version 1.4.0beta94 [November 9, 2009] CHANGES: pnggccrd.c and pngvcrd.c.
The pnglibconf.h was moved to pnglibconf.h.prebuilt(first in 1.5.0). Check the libpng CMake script shows that the configuration is consistent with Solar2D's direct reference to source code files.
The access rights of the public header files have been tightened, and getter is used to obtain the members of the data structure to avoid changes. This has been applied in platform/shared/Rtt_BitmapUtils.cpp, but Android needs to be updated.
The libpng15 dereference BUG mentioned in 2c211d807a5ef039b6f885b2deb85f49b9a3f68e just now has been tested to be normal in Emscripten with gmake in version 1.6.39. I hope it can be tested again. @bakeinflash

The modifications to libpng (may need to be forked to coronalabs by @Shchvova, and modify the corona repository reference) are:

The predefined values of NXS come from external/libpng1243b01, but it needs to be determined whether NXS's png source comes from the source code or find_package.
Copying pnglibconf.h from pnglibconf.h.prebuilt is to adapt to the custom integration methods of Emscripten with gmake, Emscripten with Visual Studio, and Android with Visual Studio. If it is migrated to CMake later, it may not be needed.
 Checking the CMake script and comparing it with the original integration method, it is not turned on. If ASM is turned on in the top-level sdk/CMakeLists.txt and then PNG_HARDWARE_OPTIMIZATIONS option is turned OFF, it will cause other third-party libraries to fail to build. Libpng should determine whether ASM is turned on to decide whether to set PNG_HARDWARE_OPTIMIZATIONS to ON. In order to reduce the scope of influence, other third-party libraries are not modified for ASM for the time being, so it is turned off temporarily.

Test
Using Sample Code Graphics/Fishies, And our colleague used over 13,000 png atlas files for testing display.newImage() read and display, and display.save() to write. The written files looked normal and were not binary-identical files:

✅ On macOS host, Android using cmake, with Java Decoder fallback disabled, test PASSED.

⚠ BUT using the command line pngtest --strict pngtest.png compiled with NDK r18b fails the test, r20b works. It seems to have no effect on writing, because Android uses Java to write, not native libpng. It is recommended to upgrade to r20b when targeting API 33 on Android, perhaps I need to fire a bug to libpng?

✅ On macOS host, Emscripten (2.0.34, consistent with Github Action) using gmake, tested normal reading, display, and save, test PASSED. (Save with no warning. Seems wasm use virtual fs instead of local storage so I can not find the real file?)
❓On Windows host, Android with Visual Studio fails to build Solar2D app (maybe incomplete for Android build?), needs to be answered and guided by documentation.
❓On Windows host, Emscripten with Visual Studio fails to build Solar2D app, needs to be answered and guided by documentation.(PR contains some fixes)
✅ Linux using find_package should not be affected, no need to test.
❓NXS needs to be tested, but because Rtt_BitmapUtils.cpp has been verified by Emscripten, there should be no problem. Can you help me test it?

Questions

Where is the original premake project for gmake? Or is it modified manually?
Where is the NXS compilation toolchain completed? Is it the same as Linux's?
Are the Visual Studio projects for Android and Emscripten complete and effective?
Are all Emscripten versions using 2.0.34? (GitHub Action, Visual Studio)
Maybe we should consider unified project development and testing? Export to different IDEs using CMake instead of maintaining them separately?
What is platform/linux/CMakeRsyncLinuxLists.txt used for?

Thank you for taking your time to read this “long text” :D

I consider marking PR as complete and continuing to investigate "the libpng failed the test on Android adb shell" elsewhere.
For the following reasons:

lpng1256 also failed the test, it is not a new issue introduced by libpng 1.6.39.
The problem only exists for native libpng writes that are not used by Android.
pngout.png "looks" same as pngtest.png.
When the first output, pngout.png, is used as input to the second pngtest, the test passes.

Test steps are as follows:
export ANDROID_NDK=~/Library/Android/sdk/ndk/18.1.5063045
export PATH=$ANDROID_NDK/toolchains/llvm/prebuilt/darwin-x86_64/bin:$PATH

# In the lpng1256 directory
mkdir build && cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK/build/cmake/android.toolchain.cmake -DANDROID_ABI=arm64-v8a -DANDROID_PLATFORM=android-21 -DPNG_HARDWARE_OPTIMIZATIONS=OFF
cmake --build .

# Ensure Android device connected, and you will need to remove symbol links before push
adb push ../../lpng1256 /data/local/tmp

# Into adb shell
adb shell

# Execute inside adb shell
export LD_LIBRARY_PATH=/data/local/tmp/lpng1256/build
cd /data/local/tmp/lpng1256/build
# Will output pngout.png and report nonidentical with pngtest.png
./pngtest --strict ../pngtest.png

Compare ../pngtest.png and pngout.png get a SHADOW:

I consider marking PR as complete and continuing to investigate "the libpng failed the test on Android adb shell" elsewhere.
For the following reasons:

lpng1256 also failed the test, it is not a new issue introduced by libpng 1.6.39.
The problem only exists for native libpng writes that are not used by Android.
pngout.png "looks" same as pngtest.png.
When the first output, pngout.png, is used as input to the second pngtest, the test passes.

Test steps are as follows:
export ANDROID_NDK=~/Library/Android/sdk/ndk/18.1.5063045
export PATH=$ANDROID_NDK/toolchains/llvm/prebuilt/darwin-x86_64/bin:$PATH

# In the lpng1256 directory
mkdir build && cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE=$ANDROID_NDK/build/cmake/android.toolchain.cmake -DANDROID_ABI=arm64-v8a -DANDROID_PLATFORM=android-21 -DPNG_HARDWARE_OPTIMIZATIONS=OFF
cmake --build .

# Ensure Android device connected, and you will need to remove symbol links before push
adb push ../../lpng1256 /data/local/tmp

# Into adb shell
adb shell

# Execute inside adb shell
export LD_LIBRARY_PATH=/data/local/tmp/lpng1256/build
cd /data/local/tmp/lpng1256/build
# Will output pngout.png and report nonidentical with pngtest.png
./pngtest --strict ../pngtest.png

Compare ../pngtest.png and pngout.png get a SHADOW:

This update eliminates the following vulnerabilities:

CVE-2011-3045
CVE-2013-6954
CVE-2013-7353
CVE-2013-7354
CVE-2014-9495
CVE-2015-0973
CVE-2016-10087
CVE-2016-3751
CVE-2017-12652

I discovered the ImageDecoder just a couple days ago, and wonder if it might be a more graceful way to update; there are some speed issues with the current Android code. (I have some related changes but don't believe I've uploaded them yet.)
(I also found this which is relevant to masks.)
Other ideas—with a focus on speed and correctness, but missing most of the non-PNG formats—might be Wuffs (see here for an implementation; I was using this on top of these features, so it might still have Windows dependencies), or fpng, although it sounds like that would be device-only (and probably want a build option + runtime-detected flag).

You're right, Thanks, I'll check it out.
This PR was supposed to eliminate CVE vulnerabilities by upgrading libpng, without considering the speed problem for the time being. If the speed and compatibility of native libpng is not as good as the built-in library of Android after a lot of tests, then we have reason to delete native libpng.


php: Rebuild for gd update

php: Rebuild for gd update

:beers: @BrewTestBot has triggered a merge.


Mistral support

I am facing the following error when trying to install from this commit?
!pip install git+https://github.com/casper-hansen/AutoAWQ.git@1c5ccc791fa2cb0697db3b4070df1813f1736208

Collecting git+https://github.com/casper-hansen/AutoAWQ.git@1c5ccc791fa2cb0697db3b4070df1813f1736208
  Cloning https://github.com/casper-hansen/AutoAWQ.git (to revision 1c5ccc791fa2cb0697db3b4070df1813f1736208) to /tmp/pip-req-build-b76l8r5y
  Running command git clone --filter=blob:none --quiet https://github.com/casper-hansen/AutoAWQ.git /tmp/pip-req-build-b76l8r5y
  Running command git rev-parse -q --verify 'sha^1c5ccc791fa2cb0697db3b4070df1813f1736208'
  Running command git fetch -q https://github.com/casper-hansen/AutoAWQ.git 1c5ccc791fa2cb0697db3b4070df1813f1736208
  Running command git checkout -q 1c5ccc791fa2cb0697db3b4070df1813f1736208
  Resolved https://github.com/casper-hansen/AutoAWQ.git to commit 1c5ccc791fa2cb0697db3b4070df1813f1736208
  error: subprocess-exited-with-error

  × python setup.py egg_info did not run successfully.
  │ exit code: 1
  ╰─> See above for output.

  note: This error originates from a subprocess, and is likely not a problem with pip.
  Preparing metadata (setup.py) ... error
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.

Could you install with --verbose so we can see the real error? @davitjnz

Thanks for the quick reply, it looks like I need to switch to A100.
  Traceback (most recent call last):
    File "<string>", line 2, in <module>
    File "<pip-setuptools-caller>", line 34, in <module>
    File "/tmp/pip-req-build-8rgnsx7y/setup.py", line 96, in <module>
      arch_flags = get_compute_capabilities()
    File "/tmp/pip-req-build-8rgnsx7y/setup.py", line 81, in get_compute_capabilities
      raise RuntimeError("GPUs with compute capability less than 8.0 are not supported.")
  RuntimeError: GPUs with compute capability less than 8.0 are not supported.


Support for applying diffs inside custom workspace directory

When you work with the Multiple SCMs plugin it's easier to work with if you check out multiple projects in separate subdirectories inside the main workspace directory. There doesn't seem to be a good way to apply a diff to one of these subdirectories - the plugin only tries to apply the diff in the current working directory (the workspace root).

Yes, this is definitely a problem.
See previous discussion at #54. I actually coded up an example fix but the reporter decided to go a different route.
For your use case it sounds like you're only applying a single diff from a single revision, is that correct?
Also, have you checked out the "Staging area" support? Upstream Phabricator developers are trying to move away from having to "arc patch" and instead providing a special git fetch URI that will automatically pull down the revision in question. For your case, that may be a cleaner solution.
Happy to add this feature though if you'd rather go with the arc patch solution.

I think you're talking about this?
https://secure.phabricator.com/D13019
That actually looks perfect for our use case. Let me see if I can make that work/whether we can update our Phabricator to get that.

Yea, so basically you enable staging areas on a per-repository basis. Then, you configure jenkins to pull from a "special" git URI instead of just master.
See https://secure.phabricator.com/T8238 for more details.
Then you can skip the "Apply Phabricator Differential" step, since the git SHA you pull will already be your differential code.
https://secure.phabricator.com/book/phabricator/article/harbormaster/
I haven't used it recently, but it should push a tag called something like phabricator/diff/123 that you can tell Jenkins to check out.


Add dashboard capacity-by-nodetype

Custom dashboards about resource utilization and node capacity (grouped by node role).

hey @bszeti it looks like there is likely some overlap between these dashboards, and the one that we have in https://github.com/redhat-cop/openshift-toolkit/tree/master/capacity-dashboard. Could you take a look at this, and maybe suggest some enhancements so that we don't end up with competing solutions in the same repo?
cc: @raffaelespazzoli @shah-zobair

Yes, the and I've talked to Raffaele about this. The "capacity" dashboards requires a special "nodegroup" label on nodes and shows the resource utilization when we have different group of compute nodes in the claster. The "capacity-by-nodetype" dashboards don't need special labels, they work with the default "role.kubernetes.io/..." label, so they can be deployed on any OpenShift v3.11 clusters. So the two dashboards show similar metrics, but were built to solve a different problem.

@bszeti ok, I would say that these dashboards should probably live in the /capacity-dashboard/ space, rather than the custom-dashboards space, which is really about deploying a customizable grafana, not about the dashboards.

@etsauer ok, at the moment the "capacity dashboards" are duplicated in the repo. They are under "capacity-dashboard" directory and also in the yaml files under "custom-dasboards/.openshift/dashboards/capacity". The purpose of "custom-dashboards" is to be able to run openshift-applier and bring up a custom Grafana with all our custom dashboards, so it's easy to try. This is what I tried to follow in the first round. Do you want me to completely remove the "capacity-by-nodetype" dashboards from there and not make them part of the openshift-applier deployment?
If yes, then I would add a new directory "capacity-by-nodetype-dashboard" (next to "capacity-dashboard") with the Grafana json files and README. Is that ok?

@bszeti rather than have the dashboards in two places, I would just point applier to the dashboard in "{{ inventory_dir }}/../../../capacity-dashboard/grafana-dashboard-capacity-by-nodetype.yml"

@etsauer I'm taking a look at this now. I see two use cases:

manually import the dashboards via Grafana UI. This requires a json files. For example /capacity-dashboard/capacity-planning.json

have the dashboard added by OpenShift Applier. This requires a yaml file ConfigMap. For example /custom-dashboards/.openshift/dashboards/capacity/dashboard-capacity.yml

Ideally the ConfigMap yaml file should somehow refer to the json files, but I don't know if it's possible. Is there a way to do something like this with the applier:
apiVersion: v1
kind: ConfigMap
data:
  namespaces-in-cluster.json: **import** {{ inventory_dir }}/../../../capacity-dashboard/namespaces-in-cluster.json
  pods-in-namespace.json: **import** {{ inventory_dir }}/../../../capacity-dashboard/pods-in-namespace.json
  summary-by-node.json: **import** {{ inventory_dir }}/../../../capacity-dashboard/summary-by-node.json
  summary-by-nodetype.json: **import** {{ inventory_dir }}/../../../capacity-dashboard/summary-by-nodetype.json

If this is not possible, then I don't know who to support both scenarios (manual import and applier) without duplicating the json definitions.

@bszeti So, I haven't tried this, but Applier supports Jinja2 templates, which has an include function. See if you can make that work. If you can it would be really nice to somehow document that approach, as this is a common sticking point with managing configmaps.
https://jinja.palletsprojects.com/en/2.10.x/templates/#include

I'm trying to use jinja like this:
{% include "namespaces-in-cluster.json" %}
or
{% include "{{ inventory_dir }}/../.openshift/dashboards/capacity-by-nodetype/namespaces-in-cluster.json" %}
or even with absolute path
{% include "/Users/bszeti/git/openshift-toolkit/custom-dashboards/.openshift/dashboards/capacity-by-nodetype/namespaces-in-cluster.json" %}
but I'm keep getting an error with applier:
TASK [openshift-applier : Process Jinja template] ********************************************************************************************************************************************************************************************
fatal: [localhost -> localhost]: FAILED! => {"changed": false, "msg": "TemplateNotFound: /Users/bszeti/git/openshift-toolkit/custom-dashboards/.openshift/dashboards/capacity-by-nodetype/namespaces-in-cluster.json"}
Any ideas? How is the template lookup done in this task?

It seems that the {% include [file] %} only works if the file is under the role. In this case "galaxy/openshift-applier/roles/openshift-applier", which is obviously not god for us. (Also "../../../../namespaces-in-cluster.json" didn't work"). Because of this I don't know how to arrange the files better than in the original commit.
Another related problem is that the included file is processed as a template so any "{{" causes issues. This later problem may be handled by adding {% raw %}...{% endraw %} in the included file...
For the record we tried:
{% macro include_namespaces_in_cluster() %}{% include 'namespaces-in-cluster.json' %}{% endmacro %}
data:
  namespaces-in-cluster.json: |
    {{ include_namespaces_in_cluster() | indent(4) }}

@etsauer Any suggestions?


[Removal]:

Hotspot Name
Urban peanut Moose
Hotspot b58 Address
112cvqzepzcq2KmD6sdCqLmmTQEe5QRrCXhaATdsNM6Z1EUn9Ms9
Discord Handle
SUFJAN
Hotspot Manufacturer
Syncrob.it
Removal Reason
I BUYED IT IN SWITZERLAND before 1 month , IT WAS EVERYTHING OK AT THE TIME OF PURCHASE
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information
I have buyed before around 1 month in switzerland it was eveything in that time, not was in explorer Deny List.
The hospot is puted in new Place  and North Macedonia.
The hospot has 5.8 Db Antena and is it in roof of my house.
Please remove it.
I Belive in Helium network and i think that the minner can be remove from Deny List.

Its oppened, by mistake.


Trouble running Playgrounds

I've successfully bootstrapped and I'm able to run the server without any issues. However, I can't get any of the playground files to run.
I open the project via:
xed .

I switch to the PointFree-Package target and that builds find. However, when I try to run a playground page (Homepage, for example), I get a warning that the playground did not compile successfully.

I don't see any errors in the editor, but there are a number of errors in the console (errors.txt).
Would you kindly let me know what I'm doing wrong here?
Thanks!

Sorry about the delay!
Playgrounds (and Xcode previews) unfortunately aren't supported in SPM modules yet, so in order for playgrounds to work one needs to generate an Xcode project. We're hoping Apple gives us this functionality soon, though!

No worries. I know you've been hard at work on TCA :)
Thanks for the update. At least I missing something obvious.


Use timespec_get if compiling with cl on Windows

Signed-off-by: A. Sinan Unur<EMAIL_ADDRESS>I built ocaml and opam using the MSVC + Cygwin tools instructions. When I ran opam install core, most dependent libraries installed without any problems, but time_now failed to install:
$ opam install time_now
[NOTE] External dependency handling not supported for OS family 'windows'.
       You can disable this check using 'opam option --global depext=false'
The following actions will be performed:
  * install time_now v0.14.0

<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
▼ retrieved time_now.v0.14.0  (cached)
[ERROR] The compilation of time_now.v0.14.0 failed at "dune build -p time_now -j 1".

#=== ERROR while compiling time_now.v0.14.0 ===================================#
# context     2.1.0~rc2 | win32/x86_64 | ocaml.4.12.0 | https://opam.ocaml.org#6609b442
# path        ~\.opam\default\.opam-switch\build\time_now.v0.14.0
# command     ~\.opam\default\bin\dune.exe build -p time_now -j 1
# exit-code   1
# env-file    ~\.opam\log\time_now-8632-6ce4ee.env
# output-file ~\.opam\log\time_now-8632-6ce4ee.out
### output ###
#           cl src/time_now_stubs.obj (exit 2)
# (cd _build/default/src && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\
VC\Tools\MSVC\14.29.30037\bin\HostX64\x64\cl.exe" -nologo -O2 -Gy- -MD -D_CRT_SECURE_NO_DEP
RECATE -nologo -O2 -Gy- -MD -I c:/opt/ocaml/lib/ocaml -I C:\opt\cygwin64\home\user\.opam\d
efault\lib\base -I C:\opt\cygwin64\home\user\.opam\default\lib\base\base_internalhash_type
s -I C:\opt\cygwin64\home\user\.[...]
# time_now_stubs.c
# time_now_stubs.c(25): fatal error C1083: Cannot open include file: 'sys/time.h': No such
file or directory

<><> Error report <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
┌─ The following actions failed
│ λ build time_now v0.14.0
└─
-─ No changes have been performed

The apparent reason is that Visual Studio does not provide a sys/time.h. However, since VS 2015, timespec_get has been available. Therefore, I added a preprocessor check for whether cl is being used to compile the C source and implemented time_now_nanoseconds_since_unix_epoch_or_zero using that function.
The check uses _MSC_VER so that the code continues to compile as usual with gcc using MinGW and Cygwin.

Thanks @nanis.  Are you able to get time_now compiling on your machine with this patch?  I don't have a WIndows machine to test this on, but the patch certainly looks reasonable.

@bcc32 Thank you. Yes, I am able to build it with the patch.
$ pwd
/cygdrive/c/Users/user/src/time_now

$ git branch
  master
* msvc-timenow

$ eval $(opam env|dos2unix)

$ ~/.opam/default/bin/dune.exe build -p time_now -j 1
          cl src/time_now_stubs.obj
time_now_stubs.c

@bcc32 I should emphasize that I did not set up separate Cygwin and MinGW environments to check those. However, I am assuming if the source continues to compile with gcc, those environments should be no worse off with this patch.

Got it, that makes sense.  I've imported this into our internal repo for review.  Thanks for contributing!

Thank you for your work and making these tools available.