ARROW-16131 [C++] support saving and retrieving custom metadata in batches for IPC file

This PR aims to address https://issues.apache.org/jira/projects/ARROW/issues/ARROW-16131
Currently, when writing an IPC file with multiple record batches using the arrow::ipc::RecordBatchWriter, the custom_metadata for each record batch is not saved and will be discarded silently.
The current writer does provide the AppendCustomMetadata API internally, but it is never called. I use this API to add the custom metadata during writing and retrieve the custom metadata when reading the record batch. I am not completely sure if this is intentionally ignored or accidentally missing, but from a user's perspective, the metadata can be set via public API (see the example case in ARROW-16131) and I think it is not very friendly that this piece of data is silently discarded.
Several test cases are added in the read_write_test.cc for verifying this change.

I checked out all the build failures reported , including arrow-gcsfs-test (Timeout) and arrow-s3-test (Failed), and they don't seem to be related with my change.
I can build and run the S3 test locally, and it ran into segfault locally as the CI server did for the test case GetFileInfoRoot:
TEST_F(TestS3FS, GetFileInfoRoot) { AssertFileInfo(fs_.get(), "", FileType::Directory); }

For the gcs test, I failed to build the google cloud cpp lib and I am not able to run it locally so far, but it seems happened in other PR as well (for example, https://github.com/apache/arrow/pull/12816)

Hmm, I don't think this is the right way to do this. The IPC message's custom_metadata is independent from record batch (i.e. schema) metadata, one should not influence the other.
(also, you could have a custom_metadata for other message types such as Tensor)
cc @wesm for opinions.

So, basically, per-message metadata is an Arrow IPC feature that's independent from record batches or schemas. That's why you don't see it mentioned in the schema metadata documentation.

If message metadata is different from schema metadata, the question here may be slightly more complex since in this case, each record batch may provide 1) this record batch's schema specific metadata, this seems not serialized/deserialized 2) this record batch's message specific metadata, we don't seem to provide API for reading/writing this

Indeed the message metadata wouldn't be attached to the record batch or schema, but passed separately.
One possible API on the write side:
class ARROW_EXPORT RecordBatchWriter {
 public:
  // (default implementation could call `WriteRecordBatch(batch)` while ignoring metadata?)
  virtual Status WriteRecordBatch(const RecordBatch& batch, const KeyValueMetadata& custom_metadata);

and on the read side:
class ARROW_EXPORT RecordBatchReader {
 public:
  // (default implementation could call `ReadNext(batch)` and reset `*custom_metadata` to null)
  virtual Status ReadNext(std::shared_ptr<RecordBatch>* batch, std::shared_ptr<KeyValueMetadata>* custom_metadata);

One possible API on the write side

Thanks for the advice. Let me give it a try.

@pitrou @lidavidm
I submitted a new commit following the suggestion above. I tried to keep the changes compatible with existing public APIs so several new APIs are added. Could you please help to review? Let me know if there is any issue. Thanks.
For the CI:

I found one test case 80 - arrow-compute-hash-join-node-test failed in C++ / AMD64 Conda C++ (pull_request), but I guess this is probably not caused by my PR
another test case 51 - arrow-flight-test (Failed) failed in continuous-integration/appveyor/pr, I am not able to find the detailed test report in the CI job, is this an issue?

@niyue Indeed, these CI failures are unrelated. I'll let @lidavidm take a look at the Flight one; the hash-join-node-test crash is at https://issues.apache.org/jira/browse/ARROW-15361

I filed ARROW-16215

I rebased the PR onto the latest master branch and resolved the conflict in read_write_test.cc.
@pitrou  @lidavidm could you please help to review if there is anything else that needs to be revised? Thanks.

Thanks a lot for your contribution @niyue !

@pitrou @lidavidm thanks so much for the detailed review


Unlock Doctrine 3.x for Contao 4.13+

This PR adjusts this extension to allow Doctrine 3.x so that it can be installed in Contao 4.13. It also fixes an issue that occurs in PHP 8.

Thank you <3


Compress images

Compress pH7CMS's assets with ImageOptim/Trimage

Done except for /data/system/modules/* but think it isn't necessary


Release as a universal wheel

By releasing as a Python wheel as well as a source distribution, you can speed up end user’s installs. After merging this command, to release you just need to run python setup.py clean sdist bdist_wheel upload.

Sorry dupe of #312


hide less-mature clients under a "more" link or similar

so that users don't get overwhelmed by too many choices that most won't use anyways

Related to:

https://github.com/matrix-org/matrix.to/issues/46
https://github.com/matrix-org/matrix.to/issues/40


Error loading model + fix

Hello amaralibey,
First of all, thank you for the fantastic work and paper.
There was an error after the recent updates when loading the model using this line:
vpr_model = torch.hub.load("amaralibey/bag-of-queries", "get_trained_boq",                                             backbone_name="dinov2", output_dim=12288)
The error:
RuntimeError: Error(s) in loading state_dict for VPRModel: 	Unexpected key(s) in state_dict: "backbone.dino.norm.weight", "backbone.dino.norm.bias".
Editing vpr_model.load_state_dict to add 'strict=False' seems to fix it:
    vpr_model.load_state_dict(         torch.hub.load_state_dict_from_url(             MODEL_URLS[f"{backbone_name}_{output_dim}"],             map_location=torch.device('cpu')         ),     strict=False     )     return vpr_model

Hello @MichaelK-rgb
Thank you for your interest and for reporting this issue :)
I am editing the entire code base to add training code and dataset download scripts.
The error is due to an update where I forgot to remove the norm layer of the DINOv2 backbone, which isn't used in BoQ. My apologies for the oversight.
I'm currently fixing this issue, so it should be resolved very soon. In the meantime, your workaround with strict=False is indeed a valid solution and will allow the model to function as expected.
Thanks again for your patience, and feel free to reach out if you encounter any other issues!
Best,


[integration-test] Introduce an environment package

This would allow to split responsabilities and require less global variables. This way, we would have one and only one global variable testEnv that can have behavior (like ensureFrozenImages, …).

This removes docker_test_vars.go and docker_utils.go init() functions to keep things sane.
This does not remove all the global variables for now to keep the diff light.
There is still a few improvements to do (on protected images)

/cc @dnephin @thaJeztah @icecrime @cpuguy83 @tiborvass
🐸
Signed-off-by: Vincent Demeester<EMAIL_ADDRESS>

I'd like to wait at least for rc5 before merging this.

all green!


Collect destination status through rabbitmq

In order to collect destination metrics (available CPU/memory) from Pulsar destinations in the network we can re-purpose the rabbitmq connection to send back htcondor status metrics which can be used for scheduling.

Producer:
1.We write a Python script that is deployed by the admin on the Pulsar side
2. The Python script will collect the metrics from the scheduler and pushes the metrics to its queue in the MQ using kombu
3. Python script should have access to the pulsar conf file (to access the MQ creds)
Consumer:
1. There will be another Python script on the consumer side running as a Telegraf task which acknowledges and fetches the metrics from the queue in the MQ
2. Compares the time stamp of the last entry in the InfluxDB to it’s local server time and pushes the new metrics and sets a field/tag for online/offline. If there is no metric in the queue then the Telegraf task will automatically set the endpoint to offline when it pushes empty/null metrics to the InfluxDB and TPV API can eliminate the specific destination from its candidates list of destination.
3. Consumer will be running on the Galaxy side (for example on the maintenance node in the EU) which will have access to the jobconf where it can access the MQ credentials of each queue.
4. Consumer telegraf task/script will be parallelized (uses multiprocessing) to talk to multiple queues in the MQ

Here is where the scripts are collected at the moment: https://github.com/pauldg/bh2024-metric-collection-scripts/

And this will be "push" mode right? I mean the connection is initiated from the Pulsar endpoint?

And this will be "push" mode right? I mean the connection is initiated from the Pulsar endpoint?

Yes, the pulsar destinations will push the metrics (interval needs to be determined) to the queue.

Many thanks for working on this!
My question is whether this tpv-metascheduler-api repository is the right one to collect destination status.
I was wondering whether we would need to have two separate repositories instead:

The existing tpv-metascheduler-api repository will execute the meta-scheduling algorithms.
A new metrics-collector repository to collect destination status and send this back to Galaxy via RabbitMQ (e.g. reusing the scripts proposed in https://github.com/usegalaxy-eu/tpv-metascheduler-api/pull/14/)

Each destination will have a metric-collector installed alongside Pulsar/ARC and HTCondor/SGE/Slurm (by the way, we should design this as an opt-in service, in case some pulsar destinations don't want to share these information?). However, there will only be one instance of the tpv-metascheduler-api service running per Galaxy instance.
What do you think?

Yes, we will move the producer script to the pulsar-depoyment repo (and/or will create a dedicated Ansible role) and add optional variable and based on this the ansible tasks for copying and setting up a corn job will make decisions. The consumer will have an Ansible role, so admins can easily install it. This consumer role will also have the telegraph task deployment tasks.
Since this is a PoC, we didn't implement the SLURM and Kubernetes metrics collection in the producer script. This will follow up. We want to create a rank function that could be added to a user's conf in the TPV and run some tests on EU to see how this works together.

xref:

https://github.com/usegalaxy-eu/tpv-metascheduler-api/pull/19
https://github.com/usegalaxy-eu/tpv-metascheduler-api/pull/20


Don't save modified documents, when running tests, upon closing the viewer (issue 18274)

/botio-linux preview

/botio integrationtest

Thank you! I have confirmed locally that the files are no longer saved to the download folder, so that's really good.


doc: fix some more typos & grammar

Fix minor typos knowning --> knowing & AOI --> API
Restructured line 38 to make more sense (unless I misunderstood it, in which case, please correct me)
Change nodejs to Node.js for consistency

@DavidSint seems like there is a conflict. Could you rebase?

@DavidSint Hi. Are you happy for me to cherry-pick your commit to master in order to not lose this changes and do not leave PR hanging? +1 is enough to get it sorted.

closed via https://github.com/nodeshift/nodejs-reference-architecture/commit/cfca93ee62947fcf476eaa907df7b8326a433ab8


Certification drop-down menu remembers un-saved changes

Looking forward for reporting a security issue:
Please report security issues by following our security policy: https://contribute.freecodecamp.org/#/security
To Reproduce
Steps to reproduce the behavior:

Go to “Create class” or “Edit Class” page, and change the selections of certifications
Click on “Cancel”
Go back to the “Create class” or “Edit Class” page and open the drop-down certifications drop-down menu
The canceled changes are pre-selected.

Expected behavior
Make sure the Certifications drop-down shows the correct previously saved certifications selections

Assigning this issue to Diego Vega, Jason Chan, and Siyuan Zhai.


Suggestion: An option to dump encoded video to disk

This would be a great way to record high quality VR footage without affecting performance, as other methods have a performance hit due to the encoder already being used by ALVR itself.
Being able to save the video that is going to be transmitted to the headset to your PC's disk as well would make for a good no-performance hit recorder with better quality than recording on the headset itself, especially if foveated encoding is disabled on ALVR.

This was implemented some days ago.


Boolean Assert Is for truth tables

Summary
I'd like to be able to write assertThat( boolean ).is( boolean ) so that code snippets like the following could be written as a junit 5 parameterized test with a truth table like supplier
Example
        for ( final PlanType planType : PlanType.values() ) {
            final boolean test2Result = mockOrganizationService.isPlanDescriptionMutable( planType );

            if ( planType.isOther() ) {
                assertThat( test2Result ).isTrue();
            }
            else {
                assertThat( test2Result ).isFalse();
            }
        }

can give a result example if desired

@xenoterracide should this issue be closed ? I'm not too sure what to think about it.

I'll close it for now, and re-open or whatever if I come up with the better use case again. I'm sure I had one but...


Apply fixes from CodeFactor

This pull request applies style fixes from code review by CodeFactor.

For more information, click here.

Codecov Report

Merging #603 (02fc463) into develop (0159c22) will decrease coverage by 0.18%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##           develop     #603      +/-   ##
===========================================
- Coverage    64.24%   64.05%   -0.19%
===========================================
  Files           35       35
  Lines         1351     1355       +4
  Branches       238      238
===========================================
  Hits           868      868
- Misses         483      487       +4

Impacted Files
Coverage Δ

packages/core/src/logger/SFPLogger.ts
51.61% <0.00%> (-3.56%)
:arrow_down:

Continue to review full report at Codecov.

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


[DISCUSS] [FlightSQL] FlightSQL versioning / compatibility levels

Describe the enhancement requested
I would like to discuss adding "versions" or "compatibility levels" to FlightSQL
Usecase
The usecase is now that FlightSQL is being adopted across products, there is an increasing number of installed clients. As we make changes / add optional features to the spec such as:

https://github.com/apache/arrow/issues/37720

The question arises "how will clients/servers know what to expect" --
At the moment, the spec defines certain features that are "optional" such as XXX (and a new optional behavior such as https://github.com/apache/arrow/pull/40243). This means:

Updates to the spec must carefully define what should happen when the client and/or server do not use the optional feature
Clients and Servers must similarly handle a variety of potentially present and missing features

An example of this subtlety is shown in the context of  https://github.com/apache/arrow/issues/37720 where we are discussing  "how should the server tell if the client is using the updated semantics"  on  https://github.com/apache/arrow/pull/40243  with @erratic-pattern  @lidavidm and @pitrou
https://github.com/apache/arrow/pull/40243#pullrequestreview-1912699524
Possible solutions
One possible
Component(s)
FlightRPC

The SqlInfo enum was/does contain this info

That said it doesn't help here when the server needs to know what the client expects

That said for this specific case, I'm somewhat inclined to punt instead of trying to solve feature/version negotiation. Would InfluxDB want to support a client that doesn't recognize the updated prepared statement handle? If not, then as long as it detects and errors when the handle is used, that should be enough. The client would just get the error a bit later.

I'm skeptical about the usefulness of this, even more when adding it somewhat late in the process like this.
Past experience on related situations:

the Arrow IPC formay has a features field that nobody uses AFAIK
the Parquet format has a version field that is not used for any particular purpose AFAIK

I pretty much agree with everything that's been said. I don't think that such a field would end up providing anything particularly useful over what exists or that would actually get used.

Would InfluxDB want to support a client that doesn't recognize the updated prepared statement handle? If not, then as long as it detects and errors when the handle is used, that should be enough. The client would just get the error a bit later.

Yes, this is likely what we would do (return an error). One potential issue raised by  @erratic-pattern is that it would not be possible to distinguish between the cases:

The client is old and doesn't know to send the updated handle
The client simply never sent the parameter values

I personally think the error could be made clear enough, but I wanted to mention this potential issue

I do think the concerns about "spec bloat" are valid. If there aren't enough of these sort of "opt-in" behaviors then it may not be worth complicating the handshake.
Echoing what Andrew said, even though we would only return an error in the case of a client that doesn't recognize the new handle, we would still want to provide clear and unambiguous error messages about what went wrong.
Currently we can get close but it's something like "No parameters provided for this prepared statement. If parameters were provided, then this FlightSQL client is possibly out of date." This is informing the user about 2 distinct possible problems instead of 1.
Another problem with this is that you could still get this error message even on the latest version of your client, simply because your client has not been updated to support it. So "out-of-date" is not necessarily true either. What actually happened is that the client does not support a capability that the server needs.
"out of date" is also a vague explanation that doesn't tell the user what went wrong. You could instead explain in more detail in the error message, but what should it say? "Your client does not support stateless prepared statements" Most users will not know what that means. Do you give a vague response or do you explain the full context of the problem? That's a lot of context to fit into a single error message in a way that's easy to understand for someone who doesn't have the related background information about the spec change. Having a concept of capabilities in the specification and documented somewhere would make it easier to explain what is happening and link to relevant information. But there are other possible solutions to this problem, for example having links to online error documentation somewhere.
There is already a sort of concept of a "feature table" according to this table in the docs. I assume this is currently resolved via the GetFlightDescriptor call? Maybe versioning at the command level as an optional metadata field on the FlightDescriptor is an option instead?
Versioning, either at the spec level or the command level, provides a straightforward error message. "Your client cannot add parameters to this prepared statement because it uses version X of this command/action/spec instead of version Y" This provides the necessary information to either research the specific root cause or come up with a solution (i.e. update your client)

Maybe the message could be
"Error: Your client either didn't send parameter values or doesn't support stateless prepared statements"
And then we could make sure the flight sql spec has a clearly labeled header / text "stateless prepared statements" that was easy for someone to discover when searching
🤔

I suppose you could also introduce a separate endpoint for binding stateless prepared statements, which itself would be a kind of versioning.


[backup] backup coordinator skips snapshots if lagged behind …

Motivation
When the backup progress can't keep up with the ledger growth, we favor timeliness over completeness.
For example, with interval 100, when we finished taking a snapshot at version 700, if we
Found the latest version is already 1250, the next snapshot we take will be at 1200, not 800.
With this, updated cluster test to continuous take snapshots (now it won't hit pruned versions).
Have you read the Contributing Guidelines on pull requests?
Test Plan
cluster test
Related PRs

/land

:broken_heart: Test Failed - commit-workflow

/land


New Ikea starkvind quirk

New quirk version for the Ikea 'STARKVIND Air purifier table'.
Just cloned the previous one with the new signature.
Also some constants have been refactored.
To fix a mypy validation a value check has been added if fan_mode and fan_mode > 1 and fan_mode < 11:.
Related to: #1846

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

14 of 19 (73.68%)  changed or added relevant lines in 9 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.05%) to 80.393%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

zhaquirks/ikea/starkvind.py
5
10
50.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.05%

Covered Lines:
6015

Relevant Lines:
7482

💛  - Coveralls

Codecov Report
Base: 80.44% // Head: 80.39% // Decreases project coverage by -0.05% :warning:

Coverage data is based on head (09110c1) compared to base (28f3399).
Patch coverage: 73.68% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##              dev    #1855      +/-   ##
==========================================
- Coverage   80.44%   80.39%   -0.06%
==========================================
  Files         240      240
  Lines        7481     7482       +1
==========================================
- Hits         6018     6015       -3
- Misses       1463     1467       +4

Impacted Files
Coverage Δ

zhaquirks/ikea/fivebtnremotezha.py
100.00% <ø> (ø)

zhaquirks/ikea/starkvind.py
50.72% <50.00%> (-0.89%)
:arrow_down:

zhaquirks/ikea/__init__.py
71.15% <100.00%> (+1.15%)
:arrow_up:

zhaquirks/ikea/blinds.py
100.00% <100.00%> (ø)

zhaquirks/ikea/fourbtnremote.py
100.00% <100.00%> (ø)

zhaquirks/ikea/motionzha.py
100.00% <100.00%> (ø)

zhaquirks/ikea/opencloseremote.py
67.74% <100.00%> (-1.01%)
:arrow_down:

zhaquirks/ikea/symfonisk.py
100.00% <100.00%> (ø)

zhaquirks/ikea/tradfriplug.py
100.00% <100.00%> (ø)

zhaquirks/ikea/twobtnremote.py
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Very nice work done !!
The second IKEA cluster is new and was first seen in Styrbar N Remote and we was not having any name of it so it was called WWAH_CLUSTER_ID  (you your imagination for interpreting it).
Then more 3rd gen device is using it i think it better giving it one more "serious" name like IKEA_CLUSTER2_ID or somthing else (perhaps IKEA_CLUSTER1_ID and IKEA_CLUSTER2_ID for 0xFC7C and 0xFC57).
I dont have any strong preference but i like the code look more serious and all is better then crappy naming without any meaning in them.
Also is the MFC cluster being used in ZHA for patching some things and can being broken is changing the names ?
Then looking on the Hex it looks it can being one bit error that IKEA have done 0xFC7C / 0xFC57 ( the second hex is having the 2 bit sett and not set > + - 2).
That is not relevant for us then the devices is on the market and we can changing the data setting in them.

Also is the MFC cluster being used in ZHA for patching some things and can being broken is changing the names ?

I don't think that the name is used, but I can check it.
I would left the cluster rename for a new PR.

The second IKEA cluster is new and was first seen in Styrbar N Remote and we was not having any name of it so it was called WWAH_CLUSTER_ID (you your imagination for interpreting it).

FYI, 0xFC57 should be the cluster ID of the "Works with all Hubs" (WWAHu) "standardized" Zigbee cluster which is now mainly used if the device is directly connected to a Alexa. I'm not sure if the IKEA devices actually implement that properly though, as I've never tried it.

Then i think the "Works with all Hubs"  /  0xFC57 shall being removed from IKEA part and moved to constants or some other place then its not manufacture (IKEA) related and can being used for more device / manufactures.
Not urgent for this PR but best fixing so not getting more python pasta slate in the future.
Thanks for explaining TheJulianJES and sharing your knowledge !!!

Then i think the "Works with all Hubs" / 0xFC57 shall being removed from IKEA part and moved to constants

Yeah, probably. I'm not sure if any other devices even have that cluster currently.
For now, moving it to the main IKEA file is a lot better already than having them in every quirk individually.

I agree but its not very urgent like getting devices working that have getting its firmware updated.
We shall putting it on the ToDo list and getting this PR merged so the users is getting full functionality in there devices.

So we feel comfortable keeping the name WWAH_CLUSTER_ID?

absolutely. I am looking for the SI document that outlines it so we can implement all of it as well.

Thanks


How to generate signatures for my own patches

Dear author,
Thank you for sharing your excellent work. I noticed that the default dataset comes from 4,219 CVE patches from NVD. I'm wondering how I should generate signatures for the patches collected on my own. Would you mind sharing the dataset collector and signature generator modules with us?
Thank you,
Wei

Hi Wei,
Unfortunately, we are not disclosing the vulnerability DB generation code because of commercial issues; only the dataset is shared. To test MOVERY with your own patches, you will inevitably have to implement a simple code yourself using the Joern parser (https://joern.io/), to extract only core code lines. During the process, if you have any questions, please send us an e-mail and we will be happy to respond.
Thank you.
Seunghoon Woo

Dear author,
Thank you for the kind advice. Recently I've been working on a recurring bug detection project and looking for opportunities to conduct comparison experiments with Movery. I have also checked other tools such as MVP but they are not available.
Could you please give me the executable to proceed with my own patches? Or may I ask if it's possible to ask for your help to generate patch signatures on your side with the security patches provided by me?
Best,
Wei


add a missing link to the "Developer API Keys page"

Looks like we updated this already: https://github.com/trello/api-docs/blob/master/app/templates/apis/webhooks.html#L23
Going to close this PR. Thanks for keeping an eye on our docs!


Update docfx.json

Adding searchScope global metadata for Azure Java SDK so that the searches are across the Azure Java TOC.
Adding specific searchScope for the big data services that are piloting cross-repo search.
Fixing ms.service for Azure Cache for Redis to be "cache" instead of "redis-cache"

Docs Build status updates of commit c507562:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

Line 220: [Error] Invalid syntax in W:\zh3s-s\docfx.json. Please validate your syntax with a JSON validator like http://jsonlint.com/ and update the JSON file in the repo with correct syntax.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 67a6a31:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

Line 220: [Error] Invalid syntax in W:\21ts-s\docfx.json. Please validate your syntax with a JSON validator like http://jsonlint.com/ and update the JSON file in the repo with correct syntax.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 4a08cc2:
:clock10: Full build: the average full build time is 73 min(s) 19 sec(s), this is based on the last 378 build(s) for this repository.

Docs Build status updates of commit 4a08cc2:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docfx.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Testing the outcome:
Before:

After:

For the specific search scopes:
view-source:https://review.docs.microsoft.com/en-us/java/api/com.microsoft.azure.management.redis?view=azure-java-stable&branch=pr-en-us-955
<meta name="scope" content="Cache for Redis, Azure, Azure Java" />
<meta name="ms.service" content="cache">

#sign-off


Dropping trailing comments

Ruby version: 2.6.2
Rubyfmt git sha: 1014a28

Input file

https://github.com/DFE-Digital/claim-additional-payments-for-teaching/blob/master/app/models/maths_and_physics/dqt_record.rb
https://github.com/DFE-Digital/claim-additional-payments-for-teaching/blob/master/db/migrate/20190613133709_create_delayed_jobs.rb

This breaks because

Comments at https://github.com/DFE-Digital/claim-additional-payments-for-teaching/blob/master/app/models/maths_and_physics/dqt_record.rb#L26-L30 are dropped
Comments at https://github.com/DFE-Digital/claim-additional-payments-for-teaching/blob/master/db/migrate/20190613133709_create_delayed_jobs.rb#L3-L13 are dropped

There are other examples of dropped trailing comments in this project, but mostly the same shape as the above two.

this should be fixed now!

🎉


Invalid samples in Module.md in MySQL module

Description:
As shown below, the sample codes for Connection Pool Handling in MySQL's module.db references invalid code. The connection url string cannot be directly provided in the MySQL module (and other DB connectors)

Describe your task(s)
Update with correct sample code.
   mysql:Client|sql:Error dbClient = new ("localhost", "rootUser", "rootPass");
Suggested Labels (optional):
module/mysql

@kaneeldias Could you send the fix as well?

@kaneeldias Could you send the fix as well?

Will do


Support auto-filtering of members based on __all__

Is your feature request related to a problem? Please describe.
By convention, Python devs use __all__ both to control what gets imported by wildcard imports, and in the same sense, define which objects are public. Currently, all non-private members will be rendered by mkdocstrings, instead of members defined in __all__.
Describe the solution you'd like
An option (enabled by default?) to tell mkdocstrings to only render objects that are added to __all__.
Describe alternatives you've considered
/
Additional context
Discussed on Gitter:
Kludex (Marcelo Trylesinski)
can I only load docstrings from objects in __all__?

pawamoy
Not natively I'm afraid. __all__ is meant for wildcard imports (explicit re-exports), so we use it like such, and to know if an alias should be resolved. There's no way yet to mark objects as "public" except for the underscore prefix convention (marking objects as private, therefore marking the rest as public)

Kludex (Marcelo Trylesinski)
thanks

dhirschfeld (Dave Hirschfeld)
__all__ is used for wildcard imports, but it's also a fairly strong convention that it denotes the public api of a module
What else is an import * for, other than import all public functions
Naming a function with an _ prefix implicitly defines it as private, by convention. Also, by convention, the public api of a module can be explicitly defined by listing it in __all__
I'm ok if tools want to ignore this long-standing convention however I think they should at least make respecting __all__ as the explicitly defined public api of a module an option
I'm not sure where the distinction between "explicitly re-exported" and public comes from - to me it is absolutely synonymous with "public"
...which means that if it's not "explicitly exported" it's intended to be private to that module... however it is named.

pawamoy
well, something could be public but not re-exported (for example to avoid ambiguity or conflicts when other modules provide an object with the same name)
I'm not against adding an option to use __all__ as the list of public objects, it's just that I'm not really satisfied with the whole situation :)
I guess the fact that from thing import * without __all__ defined imports all objects except those starting with an underscore is a strong argument in favor of "__all__ defines what is public"

Boost priority

Boost priority in our backlog through Polar.sh. Higher pledge, higher priority.
Minimum pledge by user/organization is $5, minimum amount for boost is $30.
View all issues with pledges.
We receive the funds once the issue is completed and confirmed by you.
Features with the insiders label are released to sponsors first, and tied to a funding goal.

A PR landed! :rocket:


Async transpiler plugin support

In order to add webpack support in Stryker, Stryker has to support async transpiler plugins.
This pull-request will:

Add support for asynchronous transpilers in Stryker.
Change Transpiler interface accordingly.
Change Typescript transpiler plugin accordingly.
Fix all tests that broke because of the changes that were made.

@simondel it can be merged IMO. What commit message should we use? Strictly speaking its a breaking change, but we could also state that the transpiler api is still experimental (no one is creating stryker transpilers at the moment anyway)

:+1:

@Archcry Nice job!
@nicojs I'd go with a feat for now due to the fact that it's still experimental


Update to CanJS 4.0

Checklist

[x] CanJS 4.0

https://github.com/roemhildtg/can-arcgis/commit/99667c595e75e758861f18cd23acfa83fc4c7742


Extension stopped working with vscode v1.77.3

The extension appears to have stopped working.

$  code --version
1.77.3
704ed70d4fd1c6bd6342c436f1ede30d1cff4710
x64

There's no log message in the extension console.
I'm not sure how to provide more information.

More details please ... what s/w versiona are you running; what's the definition of your highlight?

Hi @jgclark
TODO Highlight v2 (v2.0.8)
What I see:

What I tested:

Tested without any config (my settings.json without any todohighlight field) : does not work.
Tested with my normal config (has not been touched for years) : does not work.

All the test has been done in a C codebase

I am running VS Code 1.78 and TODO Highlight 2.0.8. I am also experiencing a similar issue. However, if I open a different workspace, it works sometimes. If you would like me to test anything specific let me know.

I am running VS Code 1.78 and TODO Highlight 2.0.8. I am also experiencing a similar issue. However, if I open a different workspace, it works sometimes. If you would like me to test anything specific let me know. Here is an example in my json file ...

Thanks for the details. This is what I'm seeing on VS Code 1.77.3 / extension v2.0.8.:

So it's OK for me.
As you say "it works sometimes" I wonder if you or @g-berthiaume are using a single root or a "multi-root-workspace"?

I've thought of something else for @g-berthiaume @RyanTheTechMan:
The include and exclude settings were ignored in all previous releases of the extension, so it's only from v2.0.8 that they started to take effect. (It seems the original author just didn't wire up those settings for some reason.)
So please check that those 2 settings look suitable for the files you're editing in VSCode.

Can confirm, after adding additional file extensions to the include setting highlights now work as expected.
Seeing as many users are probably going to be coming here with the same "problem", perhaps it'd be best to pin this issue?

I just added the following lines to my settings. Now knowing about this, it makes sense.
    "todohighlight.include": [
        // ...
        "**/*.cc",
        "**/*.cpp",
        "**/*.h",
        "**/*.json"
	]

There would be a better way to handle this though, such as detecting when to use highlights based on the language rather than or in addition to the file extensions. If this sounds good, you could use the "Language Mode" (Language Identifiers) of the file in the updateDecorations() function and have it default to a list of all the default supported languages in VS Code. (or similar)
If you would like me to make a fork, and do this myself, I absolutely can; though it will be a while since I am just entering finals week(s) at college!

Seeing as many users are probably going to be coming here with the same "problem", perhaps it'd be best to pin this issue?

Thanks for commenting and the suggestion; I've now renamed the issue slightly and pinned it.

Thanks for confirming it does work when you add the (now-necessary) settings.

There would be a better way to handle this though, such as detecting when to use highlights based on the language rather than or in addition to the file extensions. If this sounds good, you could use the "Language Mode" (Language Identifiers) of the file in the updateDecorations() function and have it default to a list of all the default supported languages in VS Code. (or similar)
If you would like me to make a fork, and do this myself, I absolutely can; though it will be a while since I am just entering finals week(s) at college!

I'm looking at another possible way of addressing this in #71. However, if that doesn't work out, then yes, I'd love some help to fix this, and the old request #2 about per-language support.  But, for now, focus on your finals ;-)

As suggested by @RyanTheTechMan, adding todohighlight.include to my settings did solve my problem.

A further follow-up, @RyanTheTechMan: the suggestion at #72 seems sensible to me, and looks easier than per-language settings. What do you think?

Overall, it is definitely the easier option, since most of it is already implemented. I would definitely recommend following this suggestion in #72 so that it is more of an opt-in sort of thing.
In addition, if by default, we are wanting this to work in all languages and allow customization per language, I would suggest the following:
If todohighlight.codeLanguages (or another name) is not defined, use all registered VS Code languages by default.
If todohighlight.include is not defined, follow todohighlight.codeLanguages
Allow uses to bypass by setting include to **/* or use todohighlight.everywhere. This is, of course, not recommended.
Now with help from feature request #2, todohighlight.codeLanguages can contain a list of (strings or directories), allowing the use of enabling and disabling highlights per language. todohighlight.include is then used to determine if the language and language should cause the highlights to show.
Here is a config example:
"todohighlight.codeLanguages": [
    "c", // Equivalent to { "language": "c", "globalKeywords": true, "keywords": [] }
    "cpp", // Equivalent to { "language": "cpp", "globalKeywords": true, "keywords": [] }
    "csharp", // Equivalent to { "language": "csharp", "globalKeywords": true, "keywords": [] }
    {
        "language": "java",
        "globalKeywords": false, // Defualts to false | If false, only keywords in "keywords" below will be highlighted
        "keywords": [
            {
                "text": "FIX:",
                "color": "red",
                "isWholeLine": true,
            },
        ]
    },
    {
        "language": "java",
        "globalKeywords": true, // Defualts to false | If true, all keywords in "todohighlight.keywords" will be highlighted in addition to the ones in "keywords" below
        "keywords": [
            {
                "text": "WARNING:",
                "color": "yellow",
                "isWholeLine": true,
            },
        ]
    },
],

If the extension gets "per-language support", I would think it makes the most sense to use VS Code's built-in away, since that's what it's meant to do.


Change the text width in the tex file to 80 characters

Your ProblemStatement.tex file will be improved for diffs if you use 80 characters per line.  Your editor should support hard wrapping at 80 characters.

I changed it via the TeXstudio gui to enable 80 character hard wrapping. Should be good.


E2E test overhaul to enable testing publish, file browser, etc

At the moment we are unable to test some of the core features of our system in our E2E tests since dandi-cli is a prerequisite to uploading assets. There should be some way to put the database into a predetermined "testing" state that contains sample dandisets with assets that can be used in testing. See discussion in #861

We do have this management script to create a test dandiset. Is that sufficient and/or can we expand that capability to address this issue?

We do have this management script to create a test dandiset. Is that sufficient and/or can we expand that capability to address this issue?

We discussed (very briefly) moving these to our pytest-driven tests in the django app by switching to pyppeteer, a python port of the node.js puppeteer library we're currently using. This would have some major advantages:

We could significantly scope down what each test is testing. Right now, every E2E test starts from scratch and creates a new user, new dandiset, etc. This isn't a huge problem right now because our tests are fairly simple, but as we write more complex (and useful) tests for features like publish, embargo, etc this will become increasingly unwieldy and difficult to maintain. Using pyppeteer, we could scope down each test to only test what we're actually interested in, and delegate all of the setup data to Django. We could of course leave in a few of these long-winded "true" end-to-end tests that go through the entire signup/dandiset creation process, but most tests could be simplified.

For example, as opposed to the jest-based test that tests adding owners to a dandiset that needs to manually register new users and create a dandiset in the web UI before doing any testing, using a pytest/pyppeteer approach we could do something like

def example_test(pyppeteer, dandiset):
  pyppeteer.goto(f'http://localhost:8085/dandiset/{dandiset.id}')
  pyppeteer.click(<Manage Owners button>)
  pyppeteer.fill(<owner search box>)
  pyppeteer.click(<new owner>)

  assert <some assertion that verifies a new owner has been added>

We would be using pytest for our E2E tests, which is standard girder4 that are all familiar with, as opposed to Jest.

This would enable us to test things that require asset upload (such as publish) without having to run a management script or otherwise ensure the database is in a certain state before running the tests.

Good points. If we decide to do this, I'd like for us to be careful about how these scoped-down tests will affect the state of the system, and how that in turn may affect how the order of tests reflects their outcome. That is, the major advantage of setting up all of your state for a test in one go is that you won't be subject to such wonkiness. The drawback is, of course, performance.


Errors when registering some gd classes

When registering some gd classes, the Godot editor crashes with an error.  Error immediately after "Add Chid Node".
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x20 pc=0x7ffe18757232]

goroutine 17 [running, locked to thread]:
grow.graphics/gd/gdextension.property_get_revert_func(0x4, 0x2bf1d47a9d0, 0xf20c7fd7b0)
        D:/Golang/GOPATH/pkg/mod/grow.graphics/gd@v0.0.0-20240613104355-8560ec89ebcd/gdextension/gdextension_interface.go:2456 +0x1a7
exit status 0xc0000005

Sample Code:
package main

import (
	"grow.graphics/gd"
	"grow.graphics/gd/gdextension"
)

type NewObject struct {
	gd.Class[NewObject, gd.Button]
	//gd.Class[NewObject, gd.Label]
	//gd.Class[NewObject, gd.LinkButton]
	//gd.Class[NewObject, gd.TextEdit]
	//gd.Class[NewObject, gd.CodeEdit]
	//gd.Class[NewObject, gd.ItemList]
	//gd.Class[NewObject, gd.Panel]
}

func main() {
	godot, ok := gdextension.Link()
	if !ok {
		return
	}
	gd.Register[NewObject](godot)
}

Thanks for reporting, I cannot reproduce this, what version of Godot are you using and what platform are you on>

Godot v4.2.2.stable.official [15073afe3]
https://github.com/godotengine/godot/releases/download/4.2.2-stable/Godot_v4.2.2-stable_win64.exe.zip
Microsoft Windows NT 10.0.19045.0

Can confirm this using 4.2.2 on Windows 11 with every gd.Control, gd.Button and Node3D the reported error occurs when adding it to the scene tree.
gd.Node and gd.Node2D work fine

Thanks, have reproduced this and this is fixed.


The create new Cosmos DB isn't functioning from the Azure Portal

Add an output binding > Step Three is not possible from the portal anymore... I'm also having difficulties finding a CosmosDB account I created in another Resource group, so I'm using the custom configuration tab.

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

ID: 939101cd-9c92-ed8f-b241-664794db8a0d
Version Independent ID: 21392fd3-c4e7-f785-a660-ebbbf88646e4
Content: Store unstructured data using Azure Cosmos DB and Functions
Content Source: articles/azure-functions/functions-integrate-store-unstructured-data-cosmosdb.md
Service: functions
GitHub Login: @ggailey777
Microsoft Alias: glenga

Thanks for the feedback! We are currently investigating and will update you shortly.

@timmyreilly I will close this for now. Feel free to ping me offline if you need more assistance.

@MicahMcKittrick-MSFT I think at least one issue that @timmyreilly called out needs to be fixed—we have changed the way you search for Azure services in the left-nav in the portal. Please reopen and assign to me so that I can fix the screenshot and steps under Test the function and database.

Similar problem: I don't have Cosmos DB on the list of output bindings.

@timmyreilly This should all be resolved now with recent updates to the quickstarts for v2, and some recent portal updates. #please-close. If you are still having issues, feel free to reopen this one.


GitHub Codespaces Feedback

Closing as there is no description. Please re-open if needed with more information


[BUG] Error compiling Godot for iOS with module for version 3.2.3

Describe the bug
Trying to compile for ios but getting this error at 9%:
`anischandoul@aniss-MacBook-Pro godot-3.2.3-stable % scons p=iphone tools=no target=release arch=arm
scons: Reading SConscript files ...
Checking for C header file mntent.h... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
[  9%] Compiling ==> modules/admob/src/AdMob.mm
clang: warning: optimization flag '-fomit-frame-pointer' is not supported for target 'armv7' [-Wignored-optimization-argument]
In file included from modules/admob/src/AdMob.mm:1:
In file included from modules/admob/src/AdMob.h:7:
modules/admob/src/Interstitial.h:9:36: error: no type or protocol named 'GADInterstitialDelegate' [25]
@interface Interstitial: NSObject  {
^
modules/admob/src/Interstitial.h:10:5: error: unknown type name 'GADInterstitial'; did you mean 'GADInterstitialAd'? [2]
GADInterstitial *interstitial;
^~~~~~~~~~~~~~~
GADInterstitialAd
fix-it:"modules/admob/src/Interstitial.h":{10:5-10:20}:"GADInterstitialAd"
modules/admob/lib/GoogleMobileAds.xcframework/ios-arm64_armv7/GoogleMobileAds.framework/Headers/GADInterstitialAd.h:28:12: note: 'GADInterstitialAd' declared here [2]
@interface GADInterstitialAd : NSObject
^
In file included from modules/admob/src/AdMob.mm:1:
In file included from modules/admob/src/AdMob.h:8:
modules/admob/src/Rewarded.h:10:32: error: no type or protocol named 'GADRewardedAdDelegate' [25]
@interface Rewarded: NSObject  {
^
In file included from modules/admob/src/AdMob.mm:6:
In file included from modules/admob/lib/GoogleMobileAds.xcframework/ios-arm64_armv7/GoogleMobileAds.framework/Headers/GoogleMobileAds.h:40:
In file included from modules/admob/lib/GoogleMobileAds.xcframework/ios-arm64_armv7/GoogleMobileAds.framework/Headers/GADCustomNativeAd.h:11:
modules/admob/lib/GoogleMobileAds.xcframework/ios-arm64_armv7/GoogleMobileAds.framework/Headers/GADMediaView.h:27:1: warning: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Wobjc-property-no-attribute,2]
@property(nonatomic, nullable) GADMediaContent *mediaContent;
^
modules/admob/lib/GoogleMobileAds.xcframework/ios-arm64_armv7/GoogleMobileAds.framework/Headers/GADMediaView.h:27:1: warning: default property attribute 'assign' not appropriate for object [-Wobjc-property-no-attribute,2]
In file included from modules/admob/src/AdMob.mm:8:
In file included from modules/admob/lib/UserMessagingPlatform.xcframework/ios-arm64_armv7/UserMessagingPlatform.framework/Headers/UserMessagingPlatform.h:1:
In file included from modules/admob/lib/UserMessagingPlatform.xcframework/ios-arm64_armv7/UserMessagingPlatform.framework/Headers/UMPConsentForm.h:1:
In file included from modules/admob/lib/UserMessagingPlatform.xcframework/ios-arm64_armv7/UserMessagingPlatform.framework/Headers/UMPConsentInformation.h:3:
In file included from modules/admob/lib/UserMessagingPlatform.xcframework/ios-arm64_armv7/UserMessagingPlatform.framework/Headers/UMPRequestParameters.h:1:
modules/admob/lib/UserMessagingPlatform.xcframework/ios-arm64_armv7/UserMessagingPlatform.framework/Headers/UMPDebugSettings.h:15:1: warning: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Wobjc-property-no-attribute,2]
@property(nonatomic, nullable) NSArray<NSString *> *testDeviceIdentifiers;
^
modules/admob/lib/UserMessagingPlatform.xcframework/ios-arm64_armv7/UserMessagingPlatform.framework/Headers/UMPDebugSettings.h:15:1: warning: default property attribute 'assign' not appropriate for object [-Wobjc-property-no-attribute,2]
modules/admob/src/AdMob.mm:84:60: warning: 'stringWithCString:' is deprecated: first deprecated in iOS 2.0 - Use +stringWithCString:encoding: instead [-Wdeprecated-declarations,32]
debugSettings.testDeviceIdentifiers = @[ [NSString stringWithCString: getDeviceId()] ];
^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.4.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:525:1: note: 'stringWithCString:' has been explicitly marked deprecated here [2]

(nullable id)stringWithCString:(const char *)bytes API_DEPRECATED("Use +stringWithCString:encoding: instead", macos(10.0,10.4), ios(2.0,2.0), watchos(2.0,2.0), tvos(9.0,9.0));
^
modules/admob/src/AdMob.mm:124:104: warning: 'stringWithCString:' is deprecated: first deprecated in iOS 2.0 - Use +stringWithCString:encoding: instead [-Wdeprecated-declarations,32]
GADMobileAds.sharedInstance.requestConfiguration.testDeviceIdentifiers = @ [ [NSString stringWithCString: getDeviceId()] ];
^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.4.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:525:1: note: 'stringWithCString:' has been explicitly marked deprecated here [2]
(nullable id)stringWithCString:(const char *)bytes API_DEPRECATED("Use +stringWithCString:encoding: instead", macos(10.0,10.4), ios(2.0,2.0), watchos(2.0,2.0), tvos(9.0,9.0));
^
modules/admob/src/AdMob.mm:125:87: warning: 'stringWithCString:' is deprecated: first deprecated in iOS 2.0 - Use +stringWithCString:encoding: instead [-Wdeprecated-declarations,32]
NSLog(@"on Testing Real Device: testDeviceIdentifiers: %@", [NSString stringWithCString: getDeviceId()]);
^
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.4.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:525:1: note: 'stringWithCString:' has been explicitly marked deprecated here [2]
(nullable id)stringWithCString:(const char *)bytes API_DEPRECATED("Use +stringWithCString:encoding: instead", macos(10.0,10.4), ios(2.0,2.0), watchos(2.0,2.0), tvos(9.0,9.0));
^
modules/admob/src/AdMob.mm:158:56:{158:56-158:75}{158:34-158:41}: warning: enum values with underlying type 'NSInteger' should not be used as format arguments; add an explicit cast to 'long' instead [-Wformat,33]
NSLog(@"%s : %ld", "GADMobileAds", adapterStatus.state);
~~~                   ^~~~~~~~~~~~~~~~~~~
%ld                   (long)
fix-it:"modules/admob/src/AdMob.mm":{158:34-158:37}:"%ld"
fix-it:"modules/admob/src/AdMob.mm":{158:56-158:56}:"(long)"
modules/admob/src/AdMob.mm:172:52:{172:52-172:71}{172:30-172:37}: warning: enum values with underlying type 'NSInteger' should not be used as format arguments; add an explicit cast to 'long' instead [-Wformat,33]
NSLog(@"%s : %ld", "GADMobileAds", adapterStatus.state);
~~~                   ^~~~~~~~~~~~~~~~~~~
%ld                   (long)
fix-it:"modules/admob/src/AdMob.mm":{172:30-172:33}:"%ld"
fix-it:"modules/admob/src/AdMob.mm":{172:52-172:52}:"(long)"
9 warnings and 3 errors generated.
scons: *** [modules/admob/src/AdMob.iphone.opt.arm.o] Error 1
scons: building terminated because of errors.
anischandoul@aniss-MacBook-Pro godot-3.2.3-stable % `

before this error there was another error about on interstitial.h:
#import <GoogleMobileAds/GADInterstitial.h> I changed it to #import <GoogleMobileAds/GADInterstitialAd.h>
To Reproduce
terminal and scons p=iphone tools=no target=release arch=arm
tried with master and 3.0_3.2.3 branch
and GoogleMobileAdsSdkiOS-8.3.0 and 7.69.0
Smartphone (please complete the following information):

OS: Big Sur 11.2.3

Hi, thank you for create the issue, please try with this version of GoogleMobileAdsSDK: https://github.com/Poing-Studios/Godot-AdMob-Android-iOS/releases/download/iOS_v3.0%2B/googlemobileadssdkios.zip

The correct for the master branch is #import <GoogleMobileAds/GADInterstitial.h>  because is built with version 7.69
You need to put the .framework inside this .zip into this folder: https://github.com/Poing-Studios/Godot-AdMob-Android-iOS/tree/master/ios/admob/lib

@anisc i'm waiting for Godot 3.4 versions release to update the master branch, until this you need to do these things i said above this message

I'm going to delete everything and start from a clean slate, will get back to you tomorrow but I did try both library tho. thank you for getting back to me

@anisc Ok, if this didn't solve please tell me

@gustavottc successfully built using the googlemobileadssdkios.zip you sent. thank you for your help
but it seems that only test ads work. I will try to make it work but that's a different issue.

Awesome!
The real ads only appear if you add the app on AdMob, here: https://support.google.com/admob/answer/9989980?hl=en

I was using  Shin-NiL plugin, it works great on android, but because I want to publish the app on ios too I switch to this one.

Only iOS have this issue, Android will work fine without add the app on AdMob website.
To fix this you need to publish your game to App Store and wait to appear to add, it can take some days.
I strong recommend you to use only one Plugin, using two plugin to the same thing it's not recommended.

@gustavottc Bro wanted to give you an update.
Waited waited waited sent emails to admob ... but nothing happened until today I found this website:
Google Mobile Ads SDK Developers
gave them the apple id and now I can see the ads and was able to link my app.


Update for latest OpenCL-Headers

Update to latest Khronos OpenCL-Headers repo , as per issue kenba/cl3#10 in the cl3 repo.

Changes incorporated in version 0.5.2


[Improvement suggestion] PR title created by bot

For the title of the PRs created by bot, it would be nice to have "-" between EIP & the number.
eg  #3847

could be
EIP-1444 stagnant<EMAIL_ADDRESS>I imagine the bot using "EIP-123"  would help people follow how to better refer to an EIP.

fixed by https://github.com/ethereum/EIP-Bot/commit/6e38082fb659d559a6190943dd8cbb5ebeeaecf7


Dynamically Updating Toasts

Is it possible to update a toast (by using a unique identifier) without refreshing the entire toast? forgive my ignorance if i have overlooked some part of the documentation.

This is sorted and will be out in the next release, 0.7.0
The actual mechanics of is requires a little explanation, and I'm not sure I'll be able to do the topic justice in the comment based help... so there will certainly be a blog post or two on this.
The function to keep an eye out for is Update-BTNotification

Didn't notice it it in the releases notes so I thought it was delayed - I'll work on migrating my old mass-toasts to only one that's dynamically updated, thanks !


Gather and double check list of multiplex devices

@jayna-SkylightDigital I assume this just needs to be done before the multiplex rollout?
I think we've already marked our existing devices as multiplex/not multiplex in #3476.

Closing as we're tracking comms plan offline.


proposal: x/crypto/acme: add ListCertAlternates

Let's Encrypt is going to stop returning the cross-signed chain by default starting January 11, 2021 and with that they expect to break 33% of Android devices (and 1-5% of web traffic). If you want to continue getting the cross-signed root in your certificate chain you have to download the alternative certificate via the "alternative" link relation.
This also has implications on the autocert package since this is probably something that should be exposed as an option (or even the default) to not cause issues come January.
An example of the response from a certificate request is:
HTTP/2 200
server: nginx
date: Sat, 07 Nov 2020 08:28:02 GMT
content-type: application/pem-certificate-chain
content-length: 3551
cache-control: public, max-age=0, no-cache
link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
link: <https://acme-v02.api.letsencrypt.org/acme/cert/certid/1>;rel="alternate"
x-frame-options: DENY
strict-transport-security: max-age=604800

... certificate pem ...

Right now FetchCert(ctx context.Context, url string, bundle bool) ([][]byte, error) provides no way to get the underlying headers or alternative chains. There's not an API-compatible way to extend that function. There are a few ways forward:
We could allow the user to make a request to get alternative links for a certificate and then they can manually call FetchCert on each one then parse them to determine which one they care about. This would happen after calling CreateOrderCert with the URL returned from that method.
// CertAlternatives returns a slice of alternative links for the given certificate
func (c *Client) CertAlternatives(ctx context.Context, url string) ([]string, error) {
  // HEAD request on URL then parse link headers and return where rel="alternative"
}

Alternatively to the above method, instead of returning a certificate as [][]byte from CreateOrderCert and FetchCert we could wrap it in a struct:
type Cert struct {
  DER []byte
  Chain [][]byte
  URL string
  AlternativeURLs []string
}

This would also give us the flexibility in the future for convenience methods for returning a bundle (getting rid of the current boolean option) or parsing the DER and returning *x509.Certificate or adding new fields in the future. The problem is that this would break the existing API or we'd need to add new methods and I'm not sure there's an obvious nomenclature for the new names.
My preference would be the second option if we're okay breaking the API (given that it's under x/) since it provides the most flexibility going forward. This would also cause all downstream users of this library to make a conscience decision on if they want to start using the alternative chain instead with the cross-signed root. It's not clear how many users will care about the old Android versions that the new root breaks. If we expect most people will just ignore the alternative chains then it makes sense to go with option 1 instead.

CC @FiloSottile @katiehockman

/cc @rolandshoemaker

The holidays are coming up and January 11th only a few months away, I'm willing to work on the changes for this if we can come to an agreement of how (or if) it should be solved/fixed. I brought up 2 different proposals, anyone have any thoughts on either? How comfortable are we with breaking the API of x/crypto/acme?

@rolandshoemaker any input here? Thanks!

ping @rolandshoemaker

Sorry for the lag. Given the number of users of this package I'd prefer to not break the API if we can avoid it (I suspect also that most people are unlikely to actually care about this change, and will just continue using whatever the default LE, or any other ACME provider, sends). As such I think the first option is probably preferable here.
Unfortunately there is very little context encoded in the alternative relations, so it's kind of hard to tell which of the various URLs you actually want (i.e. is the default the right chain for me, or alternative 1, or alternative 2, etc). This is complicated by there being no guarantee that the ordering is stable.
If you care about using a specific chain it seems like you'd end up needing to fetch all of the chains available in order to pick the right one correctly, since there is no way to know which of the URLs returned by CertAlternatives is the one you want. This makes me think that perhaps a FetchAllChains(url string) ([][][]byte, error) type method is perhaps more appropriate? Although I guess we could just push off the iterating and fetching of these chains to the user.

Thanks for the reply! It sounds like there are only 2 possible options left.

I suspect also that most people are unlikely to actually care about this change, and will just continue using whatever the default LE, or any other ACME provider, sends

Unfortunately I don't think many people are aware of the change to the LE roots and therefore won't realize what's happening. Therefore, I agree with your suspicion to some level. There will definitely be larger or more cognizant users that will want to prevent breakage of these older clients.

If you care about using a specific chain it seems like you'd end up needing to fetch all of the chains available in order to pick the right one correctly, since there is no way to know which of the URLs returned by CertAlternatives is the one you want.

In the more general case, that makes sense. In this one specific instance though we'd always want to use the alternative. However, given that there could be many alternatives it doesn't seem like we should make the only option to fetch all of them.

Although I guess we could just push off the iterating and fetching of these chains to the user.

I think this makes sense give the above. Should I start to work on a CL for:
CertAlternatives(ctx context.Context, url string) ([] string, error)

If there are no alternatives should it just return nil, nil?
The above solution doesn't have any API breakage which has the sole downside that people might be surprised when there are issues with older clients. I don't necessarily think it should be on Go to let them know about that though.

So this API would take the certURL from CreateOrderCert, right?
All methods are currently verbs, so we should probably follow that convention. Maybe ListCertAlternates?

So this API would take the certURL from CreateOrderCert, right?

Correct

All methods are currently verbs, so we should probably follow that convention. Maybe ListCertAlternates?

Good point, will do

@rolandshoemaker @FiloSottile so I had originally planned on making a HEAD request to the certificate URL but I'm concerned that, despite it working for Let's Encrypt, since it isn't RFC 8555 compliant it might break randomly or not work with other providers. If I follow the RFC and do a POST-as-GET then it'll get the original certificate anyways which seems like a waste to just throw it away. This is making me instead lean towards FetchAllChains but since there might be many alternatives a better option might be:
RangeAllChains(ctx context.Context, url string, f func(der [][]byte, url string) bool) error

This would first fetch the initial URL and then call the callback function. If the function returned false it would stop, otherwise continue with the next alternative chain until the callback returned false. This would allow you to keep fetching until a suitable chain was returned. For non-compliant sources we'd just fetch the initial cert internally and call the callback once.
The way that cert-manager handles this is allowing you to specify preferredChain: "DST Root CA X3" [1]. Similarly certbot has --preferred-chain option [2]. If you wanted to do something similar with RangeAllChains in your callback you'd parse the certificates and if it was a chain to the correct root you'd return false and use that chain.
[1] https://cert-manager.io/docs/configuration/acme/#use-an-alternative-certificate-chain
[2] https://github.com/certbot/certbot/pull/8080

I see the redundancy issue, but I feel like the certificate response body
is not large enough to justify the more complex API.
What happens if you pass an alternate chain URL to ListCertAlternates?
On Sun, Dec 6, 2020 at 7:45 PM James Hartig<EMAIL_ADDRESS>wrote:

@rolandshoemaker https://github.com/rolandshoemaker @FiloSottile
https://github.com/FiloSottile so I had originally planned on making a
HEAD request to the certificate URL but I'm concerned that, despite it
working for Let's Encrypt, since it isn't RFC 8555 compliant it might break
randomly or not work with other providers. If I follow the RFC and do a
POST-as-GET then it'll get the original certificate anyways which seems
like a waste to just throw it away. This is making me instead lean towards
FetchAllChains but since there might be many alternatives a better option
might be:
RangeAllChains(ctx context.Context, url string, f func(der [][]byte, url string) bool) error
This would first fetch the initial URL and then call the callback
function. If the function returned false it would stop, otherwise continue
with the next alternative chain until the callback returned false. This
would allow you to keep fetching until a suitable chain was returned. For
non-compliant sources we'd just fetch the initial cert internally and call
the callback once.
The way that cert-manager handles this is allowing you to specify preferredChain:
"DST Root CA X3" [1]. Similarly certbot has --preferred-chain option [2].
If you wanted to do something similar with RangeAllChains in your
callback you'd parse the certificates and if it was a chain to the correct
root you'd return false and use that chain.
[1]
https://cert-manager.io/docs/configuration/acme/#use-an-alternative-certificate-chain
[2] certbot/certbot#8080 https://github.com/certbot/certbot/pull/8080
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/42437#issuecomment-739545124, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJLETV6A4QQNESUDBZ5T4DSTPGLHANCNFSM4TNQVSXA
.

What happens if you pass an alternate chain URL to ListCertAlternates?

It looks like Let's Encrypt returns an alternative header with a URL of the main certificate.

Thanks for the good discussion. I hope it continues. Please try to converge to a crisp statement of what the new API (or, less great, API change) is. Thanks.

I see the redundancy issue, but I feel like the certificate response body
is not large enough to justify the more complex API.

Agreed.

What happens if you pass an alternate chain URL to ListCertAlternates?

It looks like Let's Encrypt returns an alternative header with a URL of the main certificate.

This is unfortunately underspecified, but I'd assume implementations would typically return all chains that aren't the one being requested, as the LE one does.

What happens if you pass an alternate chain URL to ListCertAlternates?

It looks like Let's Encrypt returns an alternative header with a URL of the main certificate.

That's good, so all certURLs work the same.
I think my suggestion is
// ListCertAlternates return alternate certificate chain URLs for an already issued certificate.
func (c *Client) ListCertAlternates(ctx context.Context, url string) ([]string, error)

Yep! I have a change almost ready to mail just working on tests.

@jameshartig You can go ahead and mail a CL! The proposal will transition to likely accept and then to accepted, there is nothing you need to do on that side. We can do the code review in parallel with the proposal approval.

Based on the discussion above, this seems like a likely accept.

Hello friends. The default certificate chain switch by Let's Encrypt on January 11th is approaching fast. Is there still a reasonable chance that this will be merged and released before that?

The chain switch has been postponed and it significantly changed in nature: the new chain will be compatible with old and new devices, and the only reason to use the alternate will be in order to drop compatibility is exchange for a shorter chain.
https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
We'll still land this change, but there is no rush now.

Specifically the change was pushed back to June:

Prior to that, perhaps as early as June 2021, we will be making a similar change to what we intended to make this January. When we make that change, subscribers will have the option to continue using DST Root CA X3 by configuring their ACME client to specifically request it.

Also, the alternate chain will still be offered if you don't want the new longer chain.

We currently provide the option of getting the chain: Subscriber Certificate < – R3 < – ISRG Root X1 We will continue to offer this same chain as an alternate.

No change in consensus, so accepted.

No change in consensus, so accepted.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Hello friends. The default certificate chain switch by Let's Encrypt on January 11th is approaching fast. Is there still a reasonable chance that this will be merged and released before that?

It seems that the new date for this change is September 30th. In order to support devices stuck with OpenSSL 1.0.x and the DST X3 certificate, this change seems to be required to choose the shorter chain. Otherwise these devices will no longer be able to connect. Any chance that this change will be merged before that happens?

@rolandshoemaker @rsc Can we get someone to review the mailed CL in hopes to get this merged before the end of the month?

Actually (@nbun correct me if I'm wrong), after reading [1], it seems like nothing is changing on September 29th with the default or alternate chains. This change is still useful to fetch the shorter chain if you don't need early-Android compatibility but nothing seems to be breaking in the short-term.
[1] https://community.letsencrypt.org/t/production-chain-changes/150739

@jameshartig There is a (admittedly rather small) group of devices that will be impacted by the change, see [1]. This is due to a bug in OpenSSL 1.0.x where the new default chain, which contains the soon to be expired DST X3 in last position, will be invalidated instead of accepting the certificate once the new and valid ISGR X1 is checked.
For devices where updating OpenSSL is not (easily) possible, being able to serve the alt chain without the invalid certificate at the end is critical.
[1] https://medium.com/geekculture/will-you-be-impacted-by-letsencrypt-dst-root-ca-x3-expiration-d54a018df257

OpenSSL 1.0.x has been EoL'd for almost two years now, so while we'll merge this change soon, anyone impacted by this should consider the security implications of running such an unsupported cryptography library.


Sorting a list with checked checkboxes causes intentionally unchecked boxes to revert to checked

Example: http://jsbin.com/belacoreki/edit?html,js,output
Reproduction steps:

Uncheck "ID"
Drag the sort handle anywhere in the list.

What should happen: List is reordered with checkboxes maintaining their current state (ID unchecked)
What happens: List is reordered with the ID checkbox being re-checked.
Verified issue against master and 1.5.1 release.  Regression from 1.4.2, verified does not have this issue (you can change the CDN link to https://cdnjs.cloudflare.com/ajax/libs/Sortable/1.4.2/Sortable.js to verify).

Just stumbled upon the same issue and can also validate it was working in v1.4.2.

I have also noted the issue in v1.5.1

Still an issue with v1.5.1
http://jsbin.com/dukiqafeto/edit?html,js,output
But is working with v1.4.2

I'm also running into the same issue.

I'm seeing this too, using<EMAIL_ADDRESS>and<EMAIL_ADDRESS> It only happens if you specify a drag handle, fwiw.  I just reverted to<EMAIL_ADDRESS>and the issue was resolved.

To solve this bug,
i put in comment the line "el.checked=true" in the function "_nulling":
savedInputChecked.forEach(function (el) {
//el.checked = true;
});

Problem for me as well

This is a problem on anything that uses checkboxes.

I'm experiencing this too. Took me some time to realise Sortable was the cause of the problem.
Clicking on the handle (or any control within the handle) causes ny toggled checkboxes to revert to their previous state. Any quick fix, without changing the source code, until this is fixed?

@lbowers for quick fix just use version 1.4.2 unless you need some of the features available in latest (buggy version). It helped in my case.  Maybe it isn't best solution but works.

To confirm it is related to handle and filter options
Here is a bin without handle set and checkboxes work as expected:
http://jsbin.com/vuxilaqiwi/edit?html,js,output
Here with filters (checkbox in a filter) and re-checking again occurs:
http://jsbin.com/rimehumawo/1/edit?html,js,output
Has anybody investigated if the proposed solution - removing el.checked = true; - is a valid solution and will not mess with anything or if there is any other solution that could make into PR?

Any update on this? It's causing a lot of problems in CyberChef.

It looks like this has been fixed here: https://github.com/RubaXa/Sortable/blob/master/Sortable.js#L1503
However the package version has not been updated so this fix will not pull through to any projects building from npm. Could @RubaXa increment the patch version please?
FYI, if you want a better fix that does not forget checked inputs on elements that are not currently being dragged, this might be a better solution:
	function _saveInputCheckedState(root) {
-		savedInputChecked.length = 0;
-
		var inputs = root.getElementsByTagName('input');
		var idx = inputs.length;

		while (idx--) {
			var el = inputs[idx];
-			el.checked && savedInputChecked.push(el);
+			var i = savedInputChecked.indexOf(el);
+			if (el.checked && i < 0) {
+				// el checked and not already in array
+				savedInputChecked.push(el);
+			} else if (el.checked === false && i >= 0) {
+				// el unchecked but in array
+				savedInputChecked.splice(i, 1);
+			}
		}
	}

It's been a whole year since this was reported and a fix still hasn't made its way into a release.
Why?

@RubaXa any chance this could be released anytime soon? Thanks.

Just stumbled upon this issue and felt the need to warn you guys: this is a deal breaker. Had to switch from vue-draggable that depends on this package to MooTools Sortables. Yep. That MooTools that is depracated and old like dinosaurs. But it works.
Tip: Do not use handler option and experiment with pointer-events: none; or onmousedown(event => event.preventDefault()) to disable drag on other elements except the handle to simulate the handle behavior.
@RubaXa Would you please consider putting someone else in charge of this repo?

Same problem as dominikfiala here, is there a chance for a fix to be released any soon?

@dominikfiala @PierreGuyot This issue is fixed, see comment above: https://github.com/RubaXa/Sortable/issues/1052#issuecomment-369613072
Someone just needs to take over maintaining this library and create a new release.
For our project, we just forked this repo and created a private release with the fix

Please check the latest version

The problem stills occur to me in the latest version. If I specify a handle, the checkbox is not working at all when I click on the handle. What should I do?

Yeah I'm seeing the same issue, still.
It also breaks TinyMCE, too.

I am modifying the checkboxes on the start event and on end the checkboxes are getting restored. Can we make this fix optional please?

Still an issue with v1.13.0

The problem still persists when using .filter option


Fix to support mysql module > 3.0.0

Change the possible options and names to be back in sync with the puppetlabs-mysql module in versions > 3.0.0

Hi, please have a look at https://github.com/redhat-openstack/puppet-galera/pull/10 this should fix your issue by just calling mysql module manually.

Recent changes to deprecate configuring mysql::server made this change no longer relevant.


Added: Ability to delete org avatar.

Implements #2763.
I created a new DeleteAvatar() method in the User model. Both settings router (user and org) uses this method.
Because the 'Enable Custom Avatar' option is not present in the org's settings form, after deleting the org's avatar no new custom avatar is generated, the default Gravatar picture is displayed (https://secure.gravatar.com/avatar/?s=100). Does this needs a fix? May I include the option in the org's form too, or generate a random avatar after deleting the previous?

Because the 'Enable Custom Avatar' option is not present in the org's settings form, after deleting the org's avatar no new custom avatar is generated, the default Gravatar picture is displayed (https://secure.gravatar.com/avatar/?s=100). Does this needs a fix? May I include the option in the org's form too, or generate a random avatar after deleting the previous?

I think you didn't config to disable Gravatar, if you do, I think there will be a random one generated.

You are right. If I disable Gravatar, a random avatar is generated on orgs too, after deleting the custom one.


Adding bounding boxes to image previews in Pushover notification

Hi there!
First of all... thank you for everyone's hard work on this tool. I was dreading having to set up HA purely to enable for notifications for Frigate, so this was a godsend!
The question I have - I've successfully configured Pushover to receive notifications, everything is firing correctly, but I can't seem to adjust any parameters in the included message image snapshot (specifically I'm looking to include bounding boxes in the image).
I've tinkered with camera level MQTT settings as per frigate's documentation, but changes to any parameters there don't seem to take effect? Am I messing in the wrong place? I can't quite figure out where Pushover is grabbing screenshots from.
Again, I'm just looking to include a bounding box in the preview. If this is not available, so be it!
Thanks!

Hi @b-boy-brown,
This request is about adding the bbox=1 parameter to the URLs here and here.
Perhaps the parameters timestamp, crop and quality would also be useful to define based on configuration.

Hi there - Just letting you know this was added in v0.3.3. Here's the docs for enabling this!

Amazing 😍


Video Get Freeze and sometimes video tiles is not shown

i used two component
One for participant one for active speaker .. if active speaker is detected and displayed the videos on participant list get freezes (paused ). Sometimes the video just went black and doesnot resume and active speaker view doesn't show any video  but can hear audio. this issues is so frequent ? how do i resolve it ?

Hi @pradipDevG, can you provide the following info?
Device: [e.g. Pixel3]
OS: [e.g. Android 10]
Version amazon-chime-sdk: [e.g. 0.4.0]
Version amazon-chime-sdk-media: [e.g. 0.4.0]
Can you reproduce this in the demo app?


Program crashes when using cross icon to quit

Closing the application with the cross icon at the upper right corner causes windows error "has stopped working".
Closing with menu function "DockStation -> Quit" works without error
OS:
Windows 10 Enterprise
Version 1703 (Build 15063.608)

Ok, thx. We'll check it.


e-paper display with PaperTTY

I would like to eventually manifest this as a pull request. However, it is still a hodgepodge of trial and error right now, so starting it off as an issue. Nevertheless, I managed to get a 2.7inch waveshare e-paper hat working on my pi4. All in all, it turned out to be relatively straight forward.
When logged into my Raspiblitz as user admin, I cloned https://github.com/joukos/PaperTTY and followed the install instructions (way down towards the bottom of the readme).
After install, I have been able to do things like (as admin user):
echo "Hello World" | sudo papertty.py --driver epd2in7 stdin --nofold --size 14
or, to get a full blown terminal, I can:

start a screen session and run sudo ~/.virtualenvs/papertty/bin/python3 ./papertty.py --driver epd2in7 terminal --vcsa /dev/vcsa2
in another screen session run sudo openvt -fc 2 -- sudo -u admin screen followed by screen -x <name> to attach to the screen.

At that point, both the e-paper display and my ssh console are shown the raspiblitz menu. Just a plain terminal itself would probably be preferred, but I'm not sure how to proceed from where I am. This level of shell scripting and "ttys" is quite new to me.
If, for example, I wanted the e-paper display to simply show the bestblock hash and it's height, I probably do not need a full terminal and something similar to the first command above would do. However, it seems that updating the display needs to be done by the admin user since sudo is required.
If there is a particular thing I need help with next, it is this:
What is the easiest/recommended/idiomatic way in the context of a Raspiblitz for me to have a little script run by the admin user every time, for example, a new block arrives?
My original thought was to utilize the blocknotify=<your shell command> bitcoin.conf feature. However, since the Raspiblitz runs bitcoind as user bitcoin and that user does not have sudo privileges, then if the shell command passed in required sudo, it would fail. Additionally, it seems that ZMQ is probably the preferred method in bitcoin core these days.
So, this then leads me to think that a better method might be to:

create a small service (probably written in python or something) which subscribes to any of bitcoind's ZMQ messages it might need to update the display.
then, since the service would be run by the admin user, it could execute the sudo papertty.py ... command(s) necessary to update the display.

Is this the general method that you would recommend? Thanks in advance for any pointers.
Misc Details:
The particular model I tried is https://www.amazon.com/gp/product/B07PKSZ3XK, but the foregoing seems applicable to most any other model. A model that supports partial-refresh is probably preferred for most use-cases that require a more snappy response time.

Hi. Thats a cool project. We had also in mind to provide at one point a e-paper option for the RaspiBlitz. Thanks for sharing.
@frennkie did the graphical touch display for the RaspiBlitz and there would be many details that would be best to coordinate on.
I will take a look at this once the start diving deeper into the next release - so I will mark this for milestone 1.7 - to maybe have a minimal first implementaion of a e-Paper display possible.

Great! As a first pass, it should be pretty easy to at least get the existing status display (what is currently shown on the non-touch-enabled LCDs) to display on an e-paper display if that is the goal.
At least for me, there are two primary reasons why I am interested in an e-paper display:

such a display, because it produces no backlight, is more amenable to being located in places where an LCD might be a nuisance, especially at night time
as a step towards an a low-powered/solar-powered Raspiblitz.

@philbertw4 the "4 buttons on the left side of the ePaper" you mentioned make it easier to keep have a similar interaction like the LCD-Touchscreen that also uses 4 virtual buttons on the left side .. I thin functionality will be different, but there is some consistency in there I like.
To give you a start take a look at the 00infoBlitz.shscript around line 378 ... it produces /var/cache/raspiblitz/info.json file that contains all the basic data needed to display and will be updated on the regular.
Also the file /home/admin/raspiblitz.info is a source of state during setup. For a first prototype you can display the "state/message" and the SSH login info as long as the `state!=ready.

Ok, thank you for the pointers. I'll try to put some time into this for us over the next week. Also, good idea regarding the 4 buttons on the side of the e-paper display -- I actually hadn't even noticed those buttons existed yet! I think that PaperTTY library I found and tested has no real notion of buttons though, so, while I like the idea of incorporating the buttons, that may be a next-iteration detail. As a first pass I will just start on getting the basic display showing and updating on a regular basis as you suggested.

Adding some notes here as we start digging into this:

This Article seems to have a good amount of info about how to interact with the e-paper display from scratch. It also includes some code showing how to use the buttons. Of note is the comment at the end of the article where the author recommends spending the extra $5 for the 2.9-inch e-paper display so as to be able to take advantage of partial-refresh. Sadly, the 2.9-inch does not also have any buttons.
I think having buttons would be nice, so I lean towards continuing with the 2.7-inch. However, it is important to remember that it takes multiple seconds for the display to refresh.

I think a slow display is not the problem for it to show status information. Having at least "a button" for Shutdown for the RaspiBlitz was always an important need - so "Hooray for Buttons" 👍

I like to cross-link this research - just as a keep in mind: https://github.com/rootzoll/raspiblitz/issues/1265
For better UX during SetUp it would be helpfull to detect if and what display is connected to the RaspiBlitz automatically.

Ok, thanks. Also, one more question as I get started here. I can't seem to find in the documentation the best practices for actually patching together changes like this. I have one live (mainnet) Raspiblitz node that I will be primarily doing both the development and testing on. Is the best method to use XXsyncScripts.sh pointed at my own fork? Sorry if this is already obvious to many of the other contributors.

Take a look here and let me know if there is anything missing:
https://github.com/rootzoll/raspiblitz/blob/master/FAQ.md#how-can-i-sync-a-branch-of-my-forked-github-with-my-local-raspiblitz

Started work here based off v1.6 branch: https://github.com/philbertw4/raspiblitz/tree/feature-blitzpaperui/home.admin/BlitzPaperUI Will open a pull request once I'm further along.


clock-heart link outdated

https://github.com/Psyhackological/AAA#clock-heart
Project migrated from here to here

Hi!
Thanks, done: https://github.com/Psyhackological/AAA/commit/d57c0885d8524ea6aecdedddf7eebc789bde3888


refactor listbox

Listbox Refactor:

setting activeTrigger in trigger action instead of in openMenu and in safeOnMount and in effect([open])
using early return in effect([open]) for cleaner code

Same comments as #1055


Fix replset and sharding integration tests

Fixing integration test that haven't been run for a very long time.
To be able to run integration test that require two hosts with gha I have created a custom ci workflow and set it to unmanaged in modulesync.

Finally got this working locally!
I added some tests to verify replset setup as part of mongodb::server as well.
Still don't know if it's possible to run these tests in the gha test matrix ...

Finally got all integration tests to run.
There seems to be some instability in the replset tests with mongodb 7.0 and auth enabled.
Rerunning the failing tests a few times fixes it.

Finally got all integration tests to run. There seems to be some instability in the replset tests with mongodb 7.0 and auth enabled. Rerunning the failing tests a few times fixes it.

I noticed the CentOS 8 tests failing a lot due to timeouts, nothing to do with the mongodb puppet module, but with the servers. I had a colleague trigger those again to make the pipeline pass.

We pull the centos 8 image from quay.io and that seems to trigger random timeouts :(

@stevenpost, I'm not talking about the quay.io issues. I'm aware of that :)
If you look at https://github.com/voxpupuli/puppet-mongodb/actions/runs/8719641032/job/23921963409?pr=743 it has 3 re-runs.
See each of the runs ( dropdown button to the right ) and you'll see what I'm talking about.

@stevenpost, I'm not talking about the quay.io issues. I'm aware of that :) If you look at https://github.com/voxpupuli/puppet-mongodb/actions/runs/8719641032/job/23921963409?pr=743 it has 3 re-runs. See each of the runs ( dropdown button to the right ) and you'll see what I'm talking about.

I see what you mean, and it isn't limited to MongoDB 7.0.
The members of the set are defined at line 214 (https://github.com/voxpupuli/puppet-mongodb/blob/76858968bab1a981639e8925a15346992fafcd12/spec/acceptance/replset_spec.rb#L214C11-L214C70), Do you know what the values are for x? They should map to the facts networking.fqdn, otherwise you get the error:
Notice: /Stage[main]/Main/Mongodb_replset[test]/ensure: created
Warning: Host rocky9-64-2-puppet7.example.com:27017 is available, but you are unauthorized because of authentication is enabled: true
Error: /Stage[main]/Main/Mongodb_replset[test]: Could not evaluate: rs.initiate() failed for replicaset test

Followed by
Warning: User info is available only from master host

Even though at this point, both nodes are standalone.
You are then hitting this if statement in the provider: https://github.com/voxpupuli/puppet-mongodb/blob/76858968bab1a981639e8925a15346992fafcd12/lib/puppet/provider/mongodb_replset/mongo.rb#L179 going into the else branch, which won't work with authentication enabled.

My last commit changed the outcome of the integration tests quite a bit.
Now there is no job failing on rs.initiate() any more.
The problem here seems to be that when rs.initiate() is invoked with more than one member its up to mongodb election to decide which server should be the primary(master).
The test code assumes that the host with master role ( the first host ) allways is elected as primary, which is not always the case.
When the second host is elected primary, the idempotency check on host 1 now fails auth to host 2 ...

Personally I'm not sure I like the overall design of the module when it comes to setting up replication.
I don't think I have seen puppet implementations that have to cross connect between multiple servers to get its job done ...
If I was to reimplement this I think I would somehow use exported resources for replicaset members and let puppet on the currently elected primary realize the exported the hosts trough the localhost connection.

Personally I'm not sure I like the overall design of the module when it comes to setting up replication. I don't think I have seen puppet implementations that have to cross connect between multiple servers to get its job done ...
If I was to reimplement this I think I would somehow use exported resources for replicaset members and let puppet on the currently elected primary realize the exported the hosts trough the localhost connection.

I think most modules should strive to be independent of PuppetDB, not everyone has that luxury. That being said, I agree that the current approach is suboptimal.

When the second host is elected primary, the idempotency check on host 1 now fails auth to host 2 ...

Then the check is wrong? I haven't looked at this PR it in detail yet, but some things come to mind:

Most checks can be done on a secondary node, this is great for idempotency.
Changes need to be done on the master
Adding or removing a node from the replica set needs to be done on the master
If we have a replicaset, perhaps it is ok to have the Puppet run on other nodes do the actual change. in the real world any change gets propagated throughout the replicaset anyway.

Finally I got this stabilized :)
To summarize:
7f36dacfc80483da9911b1eb0834efe3039ddb1e is needed to make sure the fist host is always elected as primary ( master )
24bb055dc8a44e98590fb141e4232e0f81ab1306 is needed to prevent misleading errors saying rs.initiate() failed for replicaset #{name} when initiation actually is successful but another host is elected as primary.
I still see lots of issues with how these replset parts are implemented in the module.
I'll try to put this up for discussion in a separate issue.

Regarding f9957b3bf23079813ca32db0c32c5ff4fd0ba38c, I really want to wait for https://github.com/voxpupuli/puppet_metadata/pull/124 and https://github.com/voxpupuli/gha-puppet/pull/53 so that I can remove it before this is merged.


IPTV playlist generation

Hi,
I would like to create a playlist like this one:
https://github.com/tnt-wolve/m3u8-1
As you can see, the target duration isn't mandatory.
Also, I would like to set the channel logo using the tvg-logo property.
How can I make it?

Hi! Interesting use of m3u8 playlists :)
EXT-X-TARGETDURATION is required in the HLS spec (RFC 8216). Maybe you can remove the tag manually after using this library?
Something like this maybe?
MediaPlaylist mediaPlaylist = MediaPlaylist.builder()
    .targetDuration(0)
    .addMediaSegments(
        MediaSegment.builder()
            .duration(0)
            .title("tvg-logo=\"logo-url\" ...")
            .uri("https://xyz.cloudfront.net/blah.m3u8")
            .build(),
        MediaSegment.builder()
            .duration(0)
            .title("tvg-logo=\"logo-url\" ...")
            .uri("https://xyz.cloudfront.net/foo.m3u8")
            .build())
    .build();

I already tought about that, but the logo should stay on the left side of the comma, while with the title property is placed on the right side

Right... Well, that kind of properties doesn't align with the EXTINF format spec (https://tools.ietf.org/html/rfc8216#section-<IP_ADDRESS>). I'm not that interested to add non-standard properties to this library, sorry!
Also, if you only want to create iptv playlists (and not read them) it should be pretty straightforward with a StringBuilder or something :)


bump ecobee version to fix issue 9190

Related issue (if applicable): fixes #9190

Thanks for looking at so quick... The hold mode for the thermo set my whole house to that mode light, alarms and etc..... If there is anything I can do let me know

After installing this, I get the following error:
2017-08-28 10:58:26 ERROR (MainThread) [homeassistant.helpers.entity] Update for climate.downstairs fails Traceback (most recent call last):   File "/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/homeassistant/helpers/entity.py", line 225, in async_update_ha_state     yield from self.hass.async_add_job(self.update)   File "/usr/lib/python3.4/asyncio/futures.py", line 388, in __iter__     yield self  # This tells Task to wait for completion.   File "/usr/lib/python3.4/asyncio/tasks.py", line 286, in _wakeup     value = future.result()   File "/usr/lib/python3.4/asyncio/futures.py", line 277, in result     raise self._exception   File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run     result = self.fn(*self.args, **self.kwargs)   File "/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/homeassistant/components/climate/ecobee.py", line 126, in update     self.data.update(no_throttle=True)   File "/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/homeassistant/util/__init__.py", line 306, in wrapper     result = method(*args, **kwargs) TypeError: update() got an unexpected keyword argument 'no_throttle'

@n0dyjeff I am unable to reproduce your latest error. How did you go about installing "this?"
I opened /srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/ecobee.py and simply changed REQUIREMENTS = ['python-ecobee-api==0.0.8'] to REQUIREMENTS = ['python-ecobee-api==0.0.9'], restarted Home Assistant, and all works well again:
2017-08-28 14:07:16 INFO (MainThread) [homeassistant.loader] Loaded ecobee from homeassistant.components.ecobee
2017-08-28 14:07:27 INFO (Thread-7) [homeassistant.util.package] Attempting install of python-ecobee-api==0.0.9
2017-08-28 14:07:37 INFO (MainThread) [homeassistant.setup] Setting up ecobee
2017-08-28 14:07:37 INFO (MainThread) [homeassistant.core] Bus:Handling <Event platform_discovered[L]: discovered=, platform=ecobee, service=load_platform.binary_sensor>
2017-08-28 14:07:37 INFO (MainThread) [homeassistant.setup] Setup of domain ecobee took 0.4 seconds.
2017-08-28 14:07:37 INFO (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=ecobee>
2017-08-28 14:07:37 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: service=ecobee, domain=notify>
2017-08-28 14:07:45 INFO (MainThread) [homeassistant.core] Bus:Handling <Event platform_discovered[L]: discovered=, platform=ecobee, service=load_platform.sensor>
2017-08-28 14:07:58 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: service=ecobee_set_fan_min_on_time, domain=climate>
2017-08-28 14:07:58 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: service=ecobee_resume_program, domain=climate>

I used the following command to install HA 0.52.1 over 0.52.0:
pip3 install --upgrade homeassistant

One difference I see is that I'm using python 3.4. The path to the file on my system is:
/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/homeassistant/components.ecobee.py
and the REQUIREMENTS statement there does show 0.0.9

I'm not sure about the throttle code, I don't think anything changed though.

I tried this again and am unable to reproduce the error. The original error was just after startup so possibly it was related to a startup timing sequence. In an case, it's working well at present. Sorry for the false alarm.

@n0dyjeff Thank you for reporting back. I will go and upgrade to 0.52.1 right now.

Works great now THANKS on 52.1