Add language tags to all annotation strings in term definitions

Allow for annotations in other languages, or multiple languages.

Solution discussed but not finalized: the pre-commit hook should add "@en" to any string that doesn't already have a language tag. This should not be part of the release process because (a) the release process should not modify the strings, and (b) we want these changes to be added permanently to the repository.
There are two parts to this solution:

Add to the pre-commit hook
Update style guide

Currently no use case for gist.
Jamie:

SPARQL 1.2 - there was one proposal to address issues around coalescing language tags and simplify the queries
Will be using language tags for DCA and IBB
Since we're also changing annotations, this would be a good time to add language tags. Old rdfs labels would stay without language tags.

MarkW: separate questions of what gist should do, what client projects should do, and what DCA should do.
A user could do a SPARQL update to add language tags if they want.
Michael proposes deferring this issue, they are implementing at Platts and can report back on how it works.
DECISION: Close and reopen if it becomes relevant again.

SPARQL 1.2 discussion here: https://github.com/w3c/sparql-12/issues/13

I'll understand if you decide not to implement it (it's your project after all) but I disagree there is no use case.
Using gist in languages other than English is unnecessarily complicated now. Mixing normal strings with language strings doesn't work well with most tools (e.g. Protege) which forces an user to first change original strings to EN lang string and only then to add additional language labels. Then repeat the process with every new gist release.

We accept that use cases may arise.  We are saying that we do not have any strong drivers for adding language tags to gist at the moment.  One of our clients does in fact want to use language tags. We will learn from that exercise about the pros and cons of different approaches and will have a better understanding of what is best for gist overall. One aspect is the impact on querying.

@gregid makes a good point: do we have a contingent of users outside the English-speaking world that are using gist?


Samples: Pinmux

Samples: Pinmux
Description
Demonstrate the use of pinmux.
This branch is just for experimentation and to spin off more branches
Reopened from https://github.com/faebryk/faebryk/pull/76
Fixes # (issue)
Checklist
Please read and execute the following:

[ ] My code follows the coding guidelines of this project
[ ] My PR title is following the contribution guidelines
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation (if applicable)
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works (if applicable)
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[ ] I ran Black to format my code

Code of Conduct
By submitting this issue, you agree to follow our Code of Conduct:

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

Pretty outdated. Simpler but functional RP2040Pinmux is for now reference.


Games

Gggg

Games support Swift Package Manager (SPM) for managing dependencies.
and if you are using Unity, Unity also support the use of Swift Package Manager (SPM) starting from Unity 2021.2 and later versions.


Adds anwalt.de services AG to the list

anwalt.de (around 100 ppl) is operating fully remote since March 2020 and will stay remote-first forever. We have offices in Nuremberg (HQ) and Berlin, and have people working from different cities in Germany (Cologne, Bremen) as well as people working from Brazil, Pakistan and Poland.

@janthurau Thank yoy!


"Connection" indicator

Played with this again, did a git reset hard to origin to update (a bit mindlessly, oops), then of course it overwrote DEFAULT_MODEL (Oh, I see there's a gui for that now in options)
An indicator somewhere for:
Is Ollama alive?
Needs starting? Responding at all ?
Is model available ( I guess on the fly model config is a whole other issue)
Needs origins configuring ? 403 (or whatever) Forbidden responses?
I guess you could use the browser action icon even.
The thing is it just seems to quietly go about doing nothing when ollama is not running.

re: models

I have various quants of the same model, dunno how often people would actually??? but yeah, I guess if there is maybe should it show tag as discriminator?!

All good feedback. There are some quick enhancements that can be made 👍


error fixed

@roygara
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@dawlysd Thanks for helping improve our docs, we appreciate it!
#sign-off


Public message to you (Game Engine Programming)

Are you looking for a C++ Game Engine/Game developer team (7 members) to gain deep knowledge? Professionals and beginners are welcome.

The engine's PBR graphics is based on DirectX 12 with a fully flexible graph based system like UE4
In addition we highly focus on our own Editor & GUI system's structure to make it better than public industry standards like (UE4, Unity, CryEngine, etc)
We always use the most modern field proven paradigms created by the best developers in the world, like, multithreaded job system used in Uncharted4's engine
Our goal is to develop an engine that is super fast and comfortable to use, We think industry standard is far behind these thinkings.

Engine Source: https://github.com/petiaccja/Inline-Engine
If you are interested send an e - mail to<EMAIL_ADDRESS>

Right now I can't find the time for it; I am developing this engine for a project course. I might reconsider for summer, depending on how much time I can spare.


Update wasm state to log

refer to changes here: https://github.com/istio/proxy/pull/2817/files
This change has broken the forwarding of metadata to ALS servers.

cc @mandarjog

/cherrypick release-1.6

@rshriram: once the present PR merges, I will cherry-pick it on top of release-1.6 in a new PR and assign it to you.

In response to this:

/cherrypick release-1.6

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@rshriram: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio
b1b68ee303cdf23fe472717824c5ddfde4fed92e
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@rshriram: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio
b1b68ee303cdf23fe472717824c5ddfde4fed92e
link
/test gencheck_istio

lint_istio
b1b68ee303cdf23fe472717824c5ddfde4fed92e
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@rshriram: new pull request created: #25007

In response to this:

/cherrypick release-1.6

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


fix: Fix broken camera push.

Fixes push to work as per :
https://docs.escoria-framework.org/en/devel/scripting/z_esc_reference.html#camera-push-target-time-type-api-doc
Fixes : https://github.com/godot-escoria/escoria-issues/issues/125

Thanks !


Fix subscription retry

https://github.com/open-cluster-management/multicloud-operators-subscription/issues/166


Contract staking

This PR introduces the support to delegate using a purse instead of a public key. It is currently a WIP, but stable enough to open a draft on.
I'll be continuing to work thru modifying existing tests and adding new tests, prior to converting from draft to actual.

bors r+

bors r+

bors r+


Azure Private Link for Azure Batch Is this Generally Available ?

As per the below link
https://azure.microsoft.com/en-us/updates/azure-private-link-for-azure-batch-is-now-generally-available-in-select-regions/
Azure Private Link for Azure Batch Is this Generally Available.
But the tutorial link says it is in public preview and not recommended for production.

Support for private connectivity in Azure Batch is currently in public preview for the West Central US, West US 2, East US, South Central US, US Gov Virginia, and US Gov Arizona regions. This preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.

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

ID: ccb356b2-fb60-e833-94c0-68e7b020949e
Version Independent ID: 06b27a8c-86c4-3f99-0393-0cc74f3e3053
Content: Use private endpoints with Azure Batch accounts - Azure Batch
Content Source: articles/batch/private-connectivity.md
Service: batch
GitHub Login: @JnHs
Microsoft Alias: jenhayes

@kspoojary
Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate.

@JnHs
Can you please check and add your comments on this doc update request as applicable.

Hi @kspoojary - I'm sorry it's taken so long to respond. I'm still working on confirming the availability and will respond when I have the confirmed information - I hope that will be very soon. Thanks for your patience!

@kspoojary, thanks for your patience! We've confirmed that support for private connectivity in Azure Batch is no longer in preview, and have updated the article accordingly to reflect the availability and regions.
I will close this issue now, but please let us know if you have further questions!
#please-close


Load html as template cache with webpack

Load all the html file as Angular template cache using some webpack plugin

Try ngtemplate-loader webpack loader


Possibly expand the password reset table a little further?

I'm an SE who had a case in which the customer was a user admin and they could not view the auth methods or change the password for a security reader. Would security admins fall under one of the already listed categories or could we add a section for them?

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

ID: eb28e967-b483-087e-6060-227289c817e1
Version Independent ID: 8dc8c4dd-e937-cf14-d12a-f2718042f1a2
Content: Privileged roles and permissions in Microsoft Entra ID (preview) - Microsoft Entra ID
Content Source: docs/identity/role-based-access-control/privileged-roles-permissions.md
Service: entra-id
Sub-service: role-based-access-control
GitHub Login: @rolyon
Microsoft Alias: rolyon

@msftmarysisko
Thanks for your feedback! We will investigate and update as appropriate.

@rolyon
I'm going to assign this to the document author so they can take a look at it accordingly.
@msftmarysisko
Can you please check and add your comments on this doc update request as applicable.

Hi @msftmarysisko
Thanks for your feedback. We've sent your feedback to the team about including the Security Administrator role in the Who can reset passwords table. We created a work item to track.
We are migrating to a new doc feedback tool, so we will close this GitHub issue. Let us know if you have additional feedback.
thanks

#please-close


Reorder the physical plan optimizer rules

Which issue does this PR close?

Closes #4678.
Rationale for this change

According to #4678, this change is done by the following steps:

Extract the global sort algorithm selection from the BasicEnforcement to be a separate rule, GlobalSortSelection.
Make the Repartition optional.
Reorder the rules as following:

AggregateStatistics
Repartition(optional)
GlobalSortSelection
JoinSelection
BasicEnforcement
CoalesceBatches(optional)

The reason for this ordering is as follows:

For Repartition, in order to increase the parallelism, it will change the output partitioning of some operators in the plan tree, which will influence other rules. Therefore, it should be run as soon as possible. The reason to make it optional is it's not used for the distributed engine, Ballista. And it's conflicted with some parts of the BasicEnforcement, since it will introduce additional repartitioning while the BasicEnforcement aims at reducing unnecessary repartitioning.
For GlobalSortSelection, since currently it will depend on the partition number to decide whether change the single node sort to parallel local sort and merge, it should be run after the Repartition. Since it will change the output ordering of some operators, it should be run before JoinSelection and BasicEnforcement, which may depend on that.
For JoinSelection, based on statistics, it will change the Auto mode to real join implementation, like collect left, or hash join, or future sort merge join, which will influence the BasicEnforcement to decide whether to add additional repartition and local sort to meet the distribution and ordering requirements. Therefore, it should be run before BasicEnforcement.
For BasicEnforcement, before run this rule, please make sure that the whole plan tree is determined.
For  CoalesceBatches, it will not influence the distribution and ordering of the whole plan tree. Therefore, to avoid influencing other rules, it should be run at last.

What changes are included in this PR?

The global sort algorithm selection is extracted from the BasicEnforcement to be a separate rule, GlobalSortSelection.
Don't insert CoalesceBatches after the Repartition.
The data of EmptyExec is aligned with the field number of its schema.
Repartition only considers the ordering influence for the final output and will not consider the intermediate data ordering especially the local ordering which should be dealt with by BasicEnforcement.

Are these changes tested?

Are there any user-facing changes?

Hi @alamb, @Dandandan, @mingmwang, could you help review this PR?

retest please

The CI check https://github.com/apache/arrow-datafusion/actions/runs/3764447841/jobs/6399000363 appears to be failing:
+----+-----------------------------+-----------------------------+
   Compiling datafusion-examples v15.0.0 (/__w/arrow-datafusion/arrow-datafusion/datafusion-examples)
    Finished dev [unoptimized + debuginfo] target(s) in 22.48s
     Running `target/debug/examples/custom_datasource`
thread 'main' panicked at 'not yet implemented', datafusion-examples/examples/custom_datasource.rs:267:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

@alamb, I don't think there is any logical conflict with #4691. I remember @mustafasrepo and I discussing this PR from that angle before and nothing came up. So unless something changed in the meantime, everybody should be OK.

Thanks @alamb, @Dandandan and @ozankabak. The UT and conflicts are refined. Could you help have a check again?


Add important information into lifecycle section of docs

I spent a little more than 1 hour today to solve this, I know this is obvious, but sometimes we don't remember...
Reference Issue
Fixes #647

I signed it!
Em qua, 10 de jul de 2019 às 14:15, googlebot<EMAIL_ADDRESS>escreveu:

Thanks for your pull request. It looks like this may be your first
contribution to a Google open source project (if not, look below for help).
Before we can look at your pull request, you'll need to sign a Contributor
License Agreement (CLA).
📝 Please visit https://cla.developers.google.com/
https://cla.developers.google.com/ to sign.
Once you've signed (or fixed any issues), please reply here (e.g. I
signed it!) and we'll verify it.
What to do if you already signed the CLA Individual signers

It's possible we don't have your GitHub username or you're using a
different email address on your commit. Check your existing CLA data
https://cla.developers.google.com/clas and verify that your email is
set on your git commits
https://help.github.com/articles/setting-your-email-in-git/.

Corporate signers

Your company has a Point of Contact who decides which employees are
authorized to participate. Ask your POC to be added to the group of
authorized contributors. If you don't know who your Point of Contact is,
direct the Google project maintainer to go/cla#troubleshoot (Public
version https://opensource.google.com/docs/cla/#troubleshoot).
The email used to register you as an authorized contributor must be
the email used for the Git commit. Check your existing CLA data
https://cla.developers.google.com/clas and verify that your email is
set on your git commits
https://help.github.com/articles/setting-your-email-in-git/.
The email used to register you as an authorized contributor must
also be attached to your GitHub account
https://github.com/settings/emails.

ℹ Googlers: Go here
https://goto.google.com/prinfo/https%3A%2F%2Fgithub.com%2FPolymer%2Flit-element%2Fpull%2F730
for more info.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Polymer/lit-element/pull/730?email_source=notifications&email_token=ACJLT2XSA22RUKVMXN6ECZDP6YKL5A5CNFSM4H7RPWYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZUENXY#issuecomment-510150367,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACJLT2W6TQJBJQITA4BYS5LP6YKL5ANCNFSM4H7RPWYA
.

You should be able to just accept the suggestions, then ping me for the merge. Thanks!

Thank you @arthurevans, in next's PR, I'll take more care;
I've accepted the changes, if you need anything, please let me know.
Thanks

No worries. Thanks for the PR!


Cleaning up the html files and moving API key to config

Thanks! However, I started refactoring frontend so that it uses Leaflet instead of Google Maps (too much hassle with the latter) - that also means I rewrote frontend code. If you're interested, changes are in forts branch.

Totally fine with that, I'll take a look at it.


restore LLD e2e tests

📝 Description
quick attempt to regen screenshots of LLD.
❓ Context

Impacted projects: lld tests
Linked resource(s): ``

✅ Checklist

[x] Test coverage
[x] Atomic delivery
[x] No breaking changes

📸 Demo

🚀 Expectations to reach
Please make sure you follow these Important Steps.
Pull Requests must pass the CI and be internally validated in order to be merged.

/generate-screenshots

#4747


how to set this footer on drawer on fix position?

i want to set fix position for text powered by reactjs on footer position inside the drawer
any idea?
like logout button position,

No idea. You should ask the people at material-ui.


GSK-1554: Making comments for the dataset and model creation consistent across notebooks.

Making comments for the dataset and model creation consistent across notebooks.

Done


EC2 Snapshot error when existing 'Name' tag is present

With the EC2 snapshot refactor, there will be a duplicate tag error if the instance being used to create a snapshot already has a tag present called Name. A new Name tag is generated from the VolumeID for use on the snapshot,  and this causes a collision with the existing Name tag on the instance.
https://github.com/capitalone/cloud-custodian/blob/master/c7n/resources/ec2.py#L1144
This seems like a potential issue with any other existing tags that overlap with the new ones generated in get_snapshot_tags().
Traceback (most recent call last):
  File "***/cloud-custodian/cloud-custodian/c7n/commands.py", line 227, in run
    policy()
  File "***/cloud-custodian/cloud-custodian/c7n/policy.py", line 707, in __call__
    resources = mode.run()
  File "***/cloud-custodian/cloud-custodian/c7n/policy.py", line 254, in run
    results = a.process(resources)
  File "***/cloud-custodian/cloud-custodian/c7n/resources/ec2.py", line 1111, in process
    raise f.exception()
ClientError: An error occurred (InvalidParameterValue) when calling the CreateSnapshot operation: Duplicate tag key 'Name' specified.

One possible workaround is to rename the new tag set being generated to something less generic, such as Snapshot_Name, or something similar, though this will still lead to a potential naming conflict.
Thoughts?

we should probably just override the name if its already given, ie. use a mapping/dict instead of a list and ensure correct ordering to population (last one wins), and then gen the list in tag value specification before we do the api call.

This feels like a policy error, their explicitly configuring copy-tags on Name, they'll lose the metadata on the ebs volume id if they do so. I'll do some work to support it (ie. no traceback) but not sure if it should be done. I'll try and capture the VolumeId to a separate tag i guess, we'll need for more advanced backup policy management (schedule keep 1 weekly, 3 monthly, etc).


Problem in view permission after using module

I have used your module to deploy a webapp on Azure. I think your job was really fascinating because it actually provides a valid webapp URL. However, I found that when I open this URL, the website shows "You do not have permission to view this directory or page." Even if I downloaded the whole zip file from GitHub and run it, such problem still occurs.
After I compare your source code with tutorial in "https://docs.microsoft.com/en-us/azure/terraform/terraform-slot-walkthru", I tried to remove one line in resource "azurerm_app_service" "webapp", that is, site_config = "${var.site_config}". Finally, the website indicates "Your App Service app is up and running." As a result, I can deploy any web applications on it, for instance, "Hello World!" in index.html.
I am curious about whether it's my fault in usage or I understand site_config incorrectly. I am looking forward to hearing from you. Thanks a lot!

Thanks @foreverXZC for trying the module.
A site_config feature is not working currently even in the terraform azurerm_app_service resource for .NET kind of webapp. If I pass any parameters in site_config for .NET webapp then it is giving error.
Currently, site_config setting is [] for .NET based webapp. If we want to use JAVA based webapp then provide the configuration mentioned in readme file.
I will fix this once it is reflected in the terraform resource.
Feel free to contribute to this module.

Thanks for reply. It really makes sense. Looking forward to the next version.

Cl


Updates to postgres connector

Fixes up links in the README (many caused by docs migration), also adds some clarification & fixes typos
Updates dependencies in relation to gradle, build scripts, docker

Merging to get up to date container to support testing


Feature/react router - Catch up to master.

Hey mate - this might be an incomplete pull request.
It works, but:

I wasn't sure about whether to add the css hash on the server index? I've left comments there
It fails the test - because it doesn't match the previous snapshot. What am I meant to be do there?
I am getting linting errors - do these need to be caught up?

Looks pretty good so far. Don't worry about snapshot testing thus far. This is a topic I need to address.
But please take a look at linting errors and try to get them sorted out. For further comments, see my review


Slow download speeds

We are facing slow download speeds in any Australia servers (speeds of few KB/s which takes around 2-5min to download the 100MB files instead of MB/s which should take around less than 30 seconds).
Using the same network but different IP address and we can get a different result.
This is not network issue related according to your Azure network ICM 507765824. If someone could please work with me to resolve the issue?

Below are several examples that looks similar to what we are facing:
https://www.reddit.com/r/GreenlightNetworks/comments/13xnhlx/slow_download_speeds_from_azure_had_to_switch/?rdt=34953
https://learn.microsoft.com/en-us/answers/questions/1321302/ultra-slow-download-speeds-from-any-service-that-u


Real Time Alarm update

Hi There,
I have this configuration but the motion alarm is a bit pointless. Can you please advise on how can I get real-time alarm updates since I will configure my security lights based on the alarm inputs.
Thanks

Instructions are already on the main page:
https://github.com/user2684/imou_life#option-3

Yes, you got the point, if you want a realtime motion sensor you need to enable push notifications, there is no other way to get this with the APIs unless polling continuously (which would hit the limit on Imou side)


node_mesh set to enable: false by default in kubernetes  cluster on Openstack

When I deploy calico 2.4.1 in kubernetes cluster "node_mesh" is set to false which make the calico bgp network lose efficacy, we using the yaml file from
https://docs.projectcalico.org/v2.4/getting-started/kubernetes/installation/hosted/calico.yaml
Expected Behavior

The default value should be "{"enabled":true}" in etcd and node-to-mesh should be enabled by default.
Current Behavior

The default value is "{"enabled":false}" in etcd and node-to-mesh is off by default.
Possible Solution
Using calico ctl to set the node_mesh
calicoctl config set nodeToNodeMesh on
Can anyone tell me when the node_mesh in etcd will be set to false by default?
Steps to Reproduce (for bugs)

Set Openstack cluster
Deploy k8s cluster in Openstack
Deploy calico by https://docs.projectcalico.org/v2.4/getting-started/kubernetes/installation/hosted/calico.yaml
the ip route is not set, since the node_mesh is not enabled by default.

Context

Your Environment

Calico version
2.4.1
Orchestrator version (e.g. kubernetes, mesos, rkt):
kubernetes 2.7.3
Operating System and version:
ubuntu 16.04

Can anyone tell me when the node_mesh in etcd will be set to false by default?

I am not aware of any instances where node_mesh is disabled by default, I do not think there are any flags/settings that would allow you to disable the mesh.  The only way I could see this happening is if you are using an etcd cluster where previously Calico was set up with node-to-node mesh disabled, could that be happening in your setup?

@tmjd, I create a fresh etcd, which just  have k8s data in it,
And do you know, which component in calico node will set the node_mesh value in etcd when boot calico node deamonset in k8s cluster,   felix ? libnetwork-plugin?
Thanks for your help

And this commit https://github.com/projectcalico/libcalico-go/pull/468 will lead to this issue on some conditions ?

@ozdanborne Think the orchestrator/openstack label is wrong here; IIUC, the OpenStack participation here is incidental - just as a lower level networking fabric - and Calico is not involved at that level.  (And also, Calico for OpenStack does not use calicoctl or YAMLs or nodeToNodeMesh.)
On the substance, it's not clear to me if the problem is just in the default YAML that we recommend people to use, or if there is also a coding problem somewhere.  @lcnsir @tmjd Is that clear to you?

@neiljerram yes, my env is that deploy k8s cluster on Openstack VMs, and create calico with the default YAML on k8s cluster.
And find that the value "nodeToNodeMesh" is off by default. which should be "on" by default.
Can you also tell me which component in calico node will set the value in etcd when it start,  felix ? libnetwork-plugin? or confd ?

@lcnsir I've been reviewing the code that I would expect to be relevant here: felix, libcalico-go and calico-node; but unfortunately I cannot see how nodeToNodeMesh is being defaulted to false.  I will need to try to reproduce your scenario, in order to understand this further.

@lcnsir You asked what component should be setting the nodeToNodeMesh. calico_node startup should be setting the nodeToNodeMesh default to on.  Here is where it happens https://github.com/projectcalico/calico/blob/master/calico_node/startup/startup.go#L803 using the value from https://github.com/projectcalico/libcalico-go/blob/master/lib/client/config.go#L50.

This issue's been open for quite some time, so I'm going to close it. @lcnsir please reopen if you still need assistance.


Nuke Enhancement: Fix|Gizmo menu is missing a lot of gizmo that are present in the shotgun pipeline

Is there an existing issue for this?

[X] I have searched the existing issues.

Please describe the feature you have in mind and explain what the current shortcomings are?
We should keep the gizmo already in present and add all that is in the Fixstudio menu in the shotgun pipeline :

How would you imagine the implementation of the feature?
add back the gizmo missing in the shotgun pipeline
Are there any labels you wish to add?

[X] I have added the relevant labels to the enhancement request.

Describe alternatives you've considered:
No response
Additional context:
No response

To test it :
Go to the "openpype_software_plugins" repository and into "/host/nuke/gizmos/".
You have all the guizmos files.
Go in Nuke, Fix sidebar menu, and compare the repository content with the Fix menu content and see if all the guizmos are present.

warning : before testing it, this ticket needs to work : https://github.com/quadproduction/OpenPype/issues/566


Release Capact 0.5.0

Description

[ ] Create new GitHub release according to the https://github.com/capactio/capact/blob/main/docs/development/release.md doc.

Make sure we use just the images that are built on the main/release branches. Do not use PR-XXX tags
Write release notes on top of the changelog (different section) and make sure they are approved by reviewers
Consider a mini blog post about the release

[ ] Tweet and share that on LinkedIn
[ ] Take a final look at our RocketChat and Mattermost manifests and verify if they run properly on a fresh VM

Reason
We're about to finish our next milestone 🚀

As we don't have this in place: https://github.com/capactio/capact/issues/494
We need to create a tarball manually, and update our website to change step for stable to use curl -Lo instead of capact alpha archive-images. Same as we have with k3s:
curl -Lo k3s-images-amd64.tar https://github.com/k3s-io/k3s/releases/download/v1.20.10%2Bk3s1/k3s-airgap-images-amd64.tar


Feature request: Rule to prevent unused/incorrect example data

I lost some time yesterday due to a tab header in an example set being different after a 'Step_arg` name change. It occurs to me this is the kind of problem a computer should solve instead of a human and it shouldn't (might) not be too hard to write a rule to check if there are any example headings not needed/used in the scenario above.
I need help because I haven't dealt with parsers and don't know what the js objects look like that burp outputs. I've tried looking at the docs but I haven't been able to find what the output objects look like.
I totally don't mind putting some time into this because it would be awesome, but I'm a bit of a noob so I could use some help :P

Hey @DwordPtr, is this type of error you would like the linter to catch?
Feature: missmatched example variables
Scenario Outline: test
Given  doesn't exist
Examples:
|v|
|1|``

Yes

Sorry Bryan, I didn't read the last part of your message carefully enough and I didn't realize you wanted to implement this yourself, till I put up the PR and came back here to ping you about it T_T
The way I have written most of these rules is by console logging a parsed file and seeing its structure.
The gherkin parser (we use the official gherkin parser package) has a set of examples, but I find it easier to writte my own feature files, console.log the generated ast, edit the file etc.
For this rule, I also looked around the gherkin source, to validate some assumptions, mostly about whether some things can be undefined, and that wasn't super tricky (I started by searching the repo for ScenarioOutlines and worked my way backwards).
Regarding the PR i put up, feel free to take a look. I want to review it again before merging with a clearer mind.


Native modules support

Lua is rich with its modules. But LuaJ seem to lack the part which is C-modules.
Anyone have an idea how C-modules can be used?
I'd ask in a community forum or chat but didn't find one.

LuaJ's "userdata" types are Java objects. You'd have to use JNI to wrap the C modules as Java objects.  Non-trivial.

I understand. That's why asking about "ideas".

Maybe there's a tool that will produce a JNI wrapping for a C API that you could use as a first step?  It looks like SWIG has some kind of support for making JNI wrappers for C code.

This whole situation with C modules makes LuaJ somewhat separated from Lua
existing ecosystem, right? Or i take it wrong?

Bearing in mind that I'm a newcomer to Lua: LuaJ strikes me as a way to embed Lua in Java apps and libraries, NOT as a platform for general Lua programming.  I wouldn't expect everything in the normal Lua ecosystem to work with LuaJ.  It's based on Lua 5.1 to begin with; any Lua library that requires 5.2+ is going to have trouble.

LuaJ not support or implement Lua C layer. So you can not use Lua C libraries.
If you need run C code you can load and run libs via Java calls like System.loadLibrary().
Go to Readme and re-read LuaJ goals.


[ES-57] add TLS options to Hashicorp SubCommand

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: macfarla:x: usmansaleemYou have signed the CLA already but the status is still pending? Let us recheck it.


Remove duplicated proxy e2e test

Description
These two e2e tests are basically the same with different checks. I moved the missing checks to one and removed the duplicated.
How can this be tested?
make test/e2e/istio
You can comment out the rest of the tests to just trigger the affected ones.
func TestIstio(t *testing.T) {
	feats := []features.Feature{
		// networkProblems.ResilienceFeature(t), // TODO: Fix so order do not matter, because its the first feature here for a reason => we don’t want to have any downloaded codemodules in the filesystem of the CSI-driver, and we can't clean the filesystem between features as the operator is not reinstalled and therefore the csi-driver is running, and you would have to mess with the database because removing it just bricks things.
		// activegate.Feature(t, proxy.ProxySpec),
		// cloudnativeDefault.Feature(t, true),
		codemodules.WithProxy(t, proxy.ProxySpec),
		// codemodules.WithProxyCA(t, proxy.ProxySpec),
	}
	testEnv.Test(t, feats...)
}

Checklist
- [ ] Unit tests have been updated/added

[X] PR is labeled accordingly with a single label
[X] I have read and understood the contribution guidelines

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (1688ada) 64.73% compared to head (18a8b60) 64.73%.

:exclamation: Current head 18a8b60 differs from pull request most recent head 8daae34. Consider uploading reports for the commit 8daae34 to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2490   +/-   ##
=======================================
  Coverage   64.73%   64.73%
=======================================
  Files         245      245
  Lines       16252    16252
=======================================
  Hits        10521    10521
  Misses       4930     4930
  Partials      801      801

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


[Tokens] Challenging shadow on leboncoin

The leboncoin team has identified a visibility problem on shadows light. They would like to challenge it.
It will also be an opportunity to create shadows for the dark theme.

Will delegate to LBC UI Team


🐞: Can't take screenshot on firefox

As mentioned on the mozzilla support page I've tried using the shortcut Ctrl +  Shift  +  S  but that didn't work. Clicking on screenshot tool after putting on the toolbar does nothing. Here's my related about:config

Toggling the last option doesn't help. I can confirm it works on FIrefox debian package, with the same config.
Firefox: v88
System: Arch Linux x86_64

It works for me on Firefox Nightly.

Yes, it does, but I don't think it is a bug with Firefox stable release, probably with the stable AppImage or some config I'm not sure which... Btw, the nightly UI looks cool.

Agreed, distro's patch original Firefox sources to enable some extra features which might be disabled on the official builds. Firefox AppImage is built from the official firefox binary. Its likely Debian did something extra, to make the Firefox screenshot work on the stable version.

Btw, the nightly UI looks cool.

Agreed, Firefox Proton redesign


Java: also build a jar file containing sources

Having a sources jar noticeably eases development of or-tools based applications, especially if done trough an IDE.

not against the idea but if its small enough why not directly add them to the original or-tool.jar ?

Thanks for your fast reply!
I just checked the size, it's just about 430 KB. So in fact your suggestion seems quite sensible.
My initial intention was to keep the changes to existing code/behaviour as little possible. Furthermore, I'm quite used to keep the sources separate from Maven.

Update: While looking for the best way/place to include the sources, I stumbled upon this: https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#searching.
In summary, including sources into the binaries jar may in some cases lead to double compiled files when including the or-tools lib in other projects which hence can interfere with or crash the classloader.
I guess there are valid arguments for both ways, especially w.r.t. the linked article. Which way would you prefer @Mizux?

Perhaps you could consider raising priority of making a Maven release? This would solve this issue as well (hence save total time). And it would make it easier to follow good practices. And I suspect it would be not too hard. And, really, it’s quite unusual for a good quality Java open source project

@oliviercailloux Actually is my top priority once the release v7.6 is out, I should have postponed it to v7.7 my bad.
I'm currently having trouble to fine good documentation on integrate native library in pom.xml and having a good loader.
So #202 is definitively not dead !
ps: I'll first try on pet project mizux/cmake-swig project which is way faster to build (no third party but still the whole swig stuff)

It is very hard to do a multi-platform maven release with native libraries
:-(
Laurent Perron | Operations Research |<EMAIL_ADDRESS>| (33) 1 42 68 53
00
Le mer. 22 avr. 2020 à 16:50, Olivier Cailloux<EMAIL_ADDRESS>a
écrit :

Perhaps you could consider raising priority of making a Maven release?
This would solve this issue as well (hence save total time). And it would
make it easier to follow good practices. And I suspect it would be not too
hard. And, really, it’s quite unusual for a good quality Java open source
project
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/or-tools/pull/1265#issuecomment-617826763, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACUPL3M2MRPGLL4N2RKYP23RN373DANCNFSM4HMDZVQQ
.

@Mizux great news!
See https://github.com/oliviercailloux/google-or-tools-java/issues/2 for my position about native libraries. Very unfortunate difficulty in Java indeed.

obsolete since we are using maven to generate java packages see #202

@Mizux Thanks for the information. Really happy to see this PR getting obsoleted in this way (Maven).


Rules from recipes not working properly

Ubuntu 12.10 / Chef 12 / Cookbook checked out from master and v1.0.0
Trying to get ufw::recipes to fetch firewall rules from recipe attributes, since using firewall_rule lwrp from firewall cookbook makes ufw::default rules disappear and be overwritten by the firewall_rule rules.
To reproduce just create a cookbook that sets up node['cookbook_name']['firewall']['rules'] and a run_list with:
"run_list": [
  "recipe[firewall::default]",
  "recipe[ufw::recipes]",
  "recipe[cookbook_name::default]"
]

and you should get rules installed from the cookbook attributes but instead i get this:
  NoMethodError
  -------------
  Undefined node attribute or method `concat' on `node'. To set an attribute, use `concat=value' instead.

  Cookbook Trace:
  ---------------
    /var/chef/cache/cookbooks/ufw/recipes/recipes.rb:37:in `block in from_file'
    /var/chef/cache/cookbooks/ufw/recipes/recipes.rb:23:in `each'
    /var/chef/cache/cookbooks/ufw/recipes/recipes.rb:23:in `from_file'

  Relevant File Content:
  ----------------------
  /var/chef/cache/cookbooks/ufw/recipes/recipes.rb:

   30:      node.set['firewall']['rules'].concat(rules) unless rules.nil?
   31:    end
   32:    # get the recipe attributes if there are any
   33:    next unless node[recipe] && node[recipe]['firewall'] && node[recipe]['firewall']['rules']
   34:
   35:    rules = node[recipe]['firewall']['rules']
   36:    Chef::Log.debug "ufw::recipes:#{recipe}:rules #{rules}"
   37>>   node.set['firewall']['rules'].concat(rules) unless rules.nil?
   38:  end
   39:
   40:  # now go apply the rules
   41:  include_recipe 'ufw::default'
   42:

Patching line 37 with the following fixes the problem:
-node.set['firewall']['rules'].concat(rules) unless rules.nil?
+node.set['firewall']['rules'] = node['firewall']['rules'].to_a.concat(rules) unless rules.nil?

Fixed on master. Thanks


Solution users have an easy way to test, visualize and validate regional failover

Copied from Azure Dev Ops Backlog
What are we trying to build in this story?
Tasks:

Alerts are sent when a failure is detected

moved to entref-appservice-containers project


Difficulty positioning a rect polygon from PhysicsEditor JSON

Version

Phaser Version: 3.22.0

Operating system: Windows 10

Browser: Chrome

Description

I've drawn a collision polygon for my matter sprite using PhysicsEditor like so:

The generated JSON:
"ground-layer": {
		"type": "fromPhysicsEditor",
		"label": "ground-layer",
		"isStatic": true,
		"density": 0.10000000149011612,
		"restitution": 0,
		"friction": 0.10000000149011612,
		"frictionAir": 0.009999999776482582,
		"frictionStatic": 0.5,
		"collisionFilter": {
			"group": 0,
			"category": 1,
			"mask": 255
		},
		"fixtures": [
			{
				"label": "",
				"isSensor": false,
				"vertices": [
					[ { "x":0, "y":54 }, { "x":0, "y":244 }, { "x":2048, "y":244 }, { "x":2048, "y":54 } ]
				]
			}
		]
	}

But my game is rendering in the center like this:

If I change the polygon to not be a perfect rect, e.g.
"vertices": [
    [ { "x":0, "y":54 }, { "x":0, "y":245 }, { "x":2048, "y":244 }, { "x":2048, "y":54 } ]
]

Then it renders exactly how it looks in PhysicsEditor:

This seems like it might be a center of mass problem, which is how Matter centers its physics bodies. It's difficult to know this for certain without seeing anything other than your JSON, but try following @CodeAndWeb's tutorial on using PhysicsEditor with Phaser 3. It explains this very well:
https://www.codeandweb.com/physicseditor/tutorials/how-to-create-physics-shapes-for-phaser-3-and-matterjs
Indeed, because this issue seems to be simply with difficulty using Phaser, PhysicsEditor and Matter, I'd suggest directing questions like these to community channels before opening a bug report, as noted in the bug report template you will have seen when posting this issue:

This repo should not be used for technical support. If you're struggling to use Phaser then post your question to the forum, Slack or Discord channels. GitHub Issues are for bugs and feature requests only.

If you can provide a code example, even when using the method mentioned in the tutorial above, please feel free to open another issue, but it must contain a code example, once again as mentioned in the bug report template:

All issues must have source code demonstrating the problem. We automatically close issues after 30 days if no code is provided.
The code can be pasted directly below this comment, or you can link to codepen, jsbin, or similar. The code will ideally be runnable instantly. The more work involved in turning your code into a reproducible test case, the longer it will take the fix the issue.

Cheers!


New results for SSL Labs API

Apparently @ivanr has added new stuff to the output of SSL Labs that we don't handle.
E.g.
Unknown detail preloadChecks

{
"sourceName" : "Chrome",
"sourceTime" :<PHONE_NUMBER>484,
"status" : "absent",
"hostname" : "xxx.xxx.nl"
},

FYI, the "hostname" part of that field is not documented and will be removed in the future. Also note that, prior to documenting everything, I changed the field names so that they make more sense. That snippet is now:
hstsPreloads":[{"source":"Chrome","hostname":
            "www.example.com","status":"present","sourceTime":
<PHONE_NUMBER>773}

Good to know. Right now I alert on unrecognised stuff.
Still like to know if I can help making the API more friendly to use.

Fixed some time ago. Closing


Long strings are truncated

Hello
The latest update introduced more polishing to the package, which is great! A small item I noticed is that long strings in the debug panel (where the values of variables are shown) are truncated. This is understandable, seeing as they are too long to display. However, something like a tooltip on hover or a way to "edit" them so their value can be copy-pasted out would be neat.
Thanks in advance and keep up the good work! This package has come a long way since its initial (somewhat buggy) release.

I am not seeing the same thing, typically the window size of the variables should grow to accommodate longer strings and you should be able to scroll right/left to see them. Can you provide a screen shot.


Pulling objects diagonally can damage you

The dmg done isnt instant crit I just recorded it with low hp for comedic effect. It also seems to stun you a bit

Closing this to concatenate into #2387


Selection Highlighting in notebooks decorations stick around after selection is gone

Testing #235047

Select a word. Notice it's highlighted in other editors.
Type

🐛 Highlights stick around the other editors
https://github.com/user-attachments/assets/1efdfbd4-d9b7-4e64-953d-21ad952d7a6c

Fixed in #236641 -- closing as a dupe to keep things cleaner.
/duplicate


updated vendors

Updated all vendors
Updated phpunit to version ~4

Fixes #124

@justinrainbow should we remove the lock file from the repo to make sure we can install things on PHP 5.3.3 as well ? the current lock file requires 5.3.23+

+1, we don't need to store the composer.lock file and can instead specify the versions of packages in composer.json itself. Pull it out and lets see how the build goes.

ref #139

@lsv please rebase per #139

Closed with https://github.com/justinrainbow/json-schema/pull/174


⚠ Fortnite has degraded performance

In 6c934ae, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1523 ms

Resolved: Fortnite performance has improved in 8279ed7.


Question: Which version(s) in 4.* series actually support PHP 8.1?

ramsey/uuid:4.0.0 declares it is compatible with PHP ^7.2 || ^8 meaning it can be installed on PHP 8.1. Clearly, it is not compatible with PHP 8.1, and follow up issues (such as #378) indicate this. Due to using ^8 in that version, history cannot be changed, so sadly, it will always and forever declare it is compatible with PHP 8.1 :sob:
So, trying to be proactive, I look at the changelog to try and find where PHP 8.1 support was introduced:
https://github.com/ramsey/uuid/blob/cd372a7b47a54734cbd491df40b5a48614d8d374/CHANGELOG.md?plain=1#L9-L98
The version constraint seems to have been changed multiple times.
My use case is: I'm maintaining a library that consumes ramsey/uuid: ^3.0|^4.0. In my CI pipeline, I've added PHP 8.1, and in the composer install --prefer-lowest, because of the above constraint that was "too wide" at the time, I will always have ramsey/uuid:4.0.0 installed. Since changing history tags is messy/terrible idea, the only practical solution for this is to adjust my own constraint to something like ramsey/uuid: ^3.0|^4.?.?, but due to the repeated changes to the version constraint in the lifetime of 4.* series, I am left confused and unsure which version is the lowest release of ramsey/uuid in the 4.* series that actually DOES support PHP 8.1.
So my question is: which release of ramsey/uuid in the 4.* series actually supports PHP 8.1 currently please?

Version 4.2.2 is the first version that truly supports PHP 8.1.
When I did that release, I thought it would be good to use ~8.1.0 and to also tag the 4.0.x and 4.1.x series with updates to limit them with ~8.0.x. I was later convinced that this had been a bad idea, so I changed everything back to ^8.0.
I’m very sorry for the confusion this caused. I’m not sure the best way to handle and communicate compatibility with future PHP versions, since PHP itself doesn’t follow semver.

There was a thread somewhere (maybe on Twitter?) where I think I discussed these changes with @Ocramius, but I can’t seem to find it now.

Yes indeed; FWIW, my approach tends to be something like 7.1.*|7.2.*|7.3.*|7.4.*|8.0.*|8.1.* for example, to be moderately specific :) Thank you for getting back to me Ben, I'll pin to ^3.0|^4.2.2 and that should solve things :+1:


Bug: $cordovaLocalNotification is not aligned with cordova-plugin-local-notifications

Hi guys,
When trying to use the "add()" method of the plugin mentioned above I receive the message:
"Depreated: Please use notification.local.schedule instead."
BTW - there are other API's which might be useful to introduce to ngCordova wrapper such as "get()".
Many thanks and keep on the good work!

Update $cordovaLocalNotification
$cordovaLocalNotification: 'add' event not fired; proposed pull request ignored
Update $cordovaLocalNotification to latest plugin version
Update $cordovaLocalNotification documentation

@mbarzeev the pull request is merged. You can close the issue now.
Thank you!

Many thanks :)


Correct typo

The paragraph started with
'lso'
Pretty sure it was supposed to start with
'Also'.
No other changes.

:white_check_mark: Validation status: passed
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.

@davidroberts63 thanks for catching that 👍


Fix broken sql query in code example

Broken code on page https://logux.io/recipes/authentication/
Before:

After:

Thanks


Add support for Beagle imputed VCFs

Hi Jonathan, I got the following error after running pytest.
trtools/dumpSTR/tests/test_dumpSTR.py::test_zippedOutput - FileNotFoun...
trtools/dumpSTR/tests/test_dumpSTR.py::test_TwoDumpSTRRounds - FileNot...
trtools/dumpSTR/tests/test_dumpSTR.py::test_BrokenVCF - TypeError: Rec...

The first two "FileNotFound" are due to the missing tabix tool under my environment, I'm not sure do we need to add a note that tabix should be installed, which might be a common sense.
The third one is trtools/utils/tr_harmonizer.py:294: TypeError. Not sure whether it is a issue with the vcd file or the way how I'm running it.
I'll keep go through the details of the changes.

Hey Yang, I've addressed your comments!

Thanks. I think it looks great! I add a line in the trtools_prep_beagle_vcf.sh script to remove $temp_file if the scripts failed, feel free to remove it if that not make sense.
Two questions about the documentation:

It seems the there are a few parameters in TRtools are not supported if data is from beagle, do we need to point out those in the notes?
I can see in the reference file you provided contains INFO fields like START END PERIOD. I could find those fields/annotation from the reference files downloaded from our lab website. Do we need provide how to add those annotation to the reference file?
Thanks,
Yang

Thanks. I think it looks great! I add a line in the trtools_prep_beagle_vcf.sh script to remove $temp_file if the scripts failed, feel free to remove it if that not make sense. Two questions about the documentation:

Thanks for pointing this out! You're right that the script should act cleanly when its dependencies aren't present.
It's important to figure out what the script should do when it meets an error condition, which is not normally to continue on silently. Here the script needs tabix in order to run properly, so it should error out when tabix is not present. I've changed the code to reflect that.

It seems the there are a few parameters in TRtools are not supported if data is from beagle, do we need to point out those in the notes?

There's a brief line in the dumpSTR doc saying that we don't have any call-level filters for Beagle at the moment. Do you have any other parameters/notes in mind?

I can see in the reference file you provided contains INFO fields like START END PERIOD. I could find those fields/annotation from the reference files downloaded from our lab website. Do we need provide how to add those annotation to the reference file?

Yep! Will email generate the files needed to fix this and email you separately.

Thanks,
Yang

I appreciate the review!
@mgymrek I believe I've addressed all your comments


Support Laravel 11

Added dependency list to support Laravel 11

Closing https://github.com/rawilk/laravel-webauthn/issues/24

@rawilk Would be awesome if we could get this merged in 🙌  Thanks!


Getting the postal for another script that can display it in text

Any lua coders know how I could display the postal in another script?
I want to display the postals in 911 calls that are automated.
But not sure what export if possible I can use or what I can do to reference the postal from this script.
I did notice: exports('getPostal', function() return nearest and nearest.code or nil end) in cl.lua
and my code: local postal = exports["nearest-postal"]:getPostal()
But yet I get errors for No such export getPostal in resource nearest-postal
any ideas?
cc: @DevBlocky @GoatG33k @MichaelCoding25 @DawsonGodin

I also tried adding the exports to the fxmanifest of nearest-postal resource and the dependency to fxmanifest of the 911 script I am using
from nearest-postal fxmanifest
exports {
    "getPostal"
}

server_exports {
    "getPostal"
}

from my resource fxmanifest:       dependency "nearest-postal"

Managed to get it to work with some changes.

@Legacy-TacticalGamingInteractive Can you tell me how you got it to work? I'm trying to setup a simple teleport to AOP script but adding a chat message for when it's used to prevent people from abusing it while in the AOP already so I want it to tell me what postal they came from.

@Legacy-TacticalGamingInteractive Can you tell me how you got it to work? I'm trying to setup a simple teleport to AOP script but adding a chat message for when it's used to prevent people from abusing it while in the AOP already so I want it to tell me what postal they came from.

sorry bro i gave up i dont use nearest postal anymore sorry i cant be more help


Trades not being posted by the bot

Hi there, thank you for the work on this!
I have the bot working, I just dropped someone and the notification went as expected.
However we just had a trade in the league and nothing came from the bot to the channel.
Here's our list of recent transactions:

Only the drop made it through the bot:

Could there be some configuration I'm missing? Happy to provide more information if you need me to.
Thanks!

Do you have the web dyno on? It must be off fo the bot to work correctly, or it will shut itself down after 30min. Its a Herkou thing, so please shut that off if it is on, and restart the boy dyno.

Yes, I had the web dyno off. I think that is why the drop notification worked.

If another trade happens and it fails again, please ping me. It has worked for others so odd it's not working for you. Did you just set the bot up?

I set it up a couple of days ago. I'll try and get another of our teams to attempt a trade to see if it works. I'll update you when we can make that happen. Thanks!

Yah please do. I don't think Yahoo changed their API so it should pickup trades for sure. Just make sure the web dyno is off after authenticating.


Additional modules

Fixes #47
The thinking here is it's better to show any module in the build.gradle.kts, even as a commented out line, rather than have them be absent and wonder why.

Great! Shall I leave merge & (eventual) doc update to you such that you're in control there?
Locally the run command worked just fine.

I'll go ahead and merge this in and then see next week when I run it how it goes. Thanks :)


source code?

unfurtunately, there is no source code for compilation. Do you plan to provide it?
Than you

unfurtunately, there is no source code for compilation. Do you plan to provide it? Than you

We may release some source code later, but we will not directly open the part that communicates with the device.This library is modified from the C++ one, but I found some problems during the modification process and fixed them. I will find time to update the C++ library later.https://github.com/MiraboxSpace/Windows-StreamDock-CPPSDK


ImRead get Mat of zero rows and zero columns

Summary of your issue
I have an image file barcode.jpg.
I use the statement

Mat mat =<EMAIL_ADDRESS>ImreadModes.Grayscale);

and get mat with zero rows.
The image file barcode.jpg, with 206 rows 500 columns,  can be inspected corrected by double clicked it in windows explorer.
barcode.jpg

.
Environment
Windows 10, OpenCVSharp4.Windows
What did you do when you faced the problem?
//write here
Example code:
		static void Main(string[] args)
		{
			Mat mat = Cv2.ImRead(@"d:\downloads\barcodes\barcode.jpg", ImreadModes.Grayscale);
			Console.WriteLine($"barcode.jpg : Rows={mat.Rows}, Cols={mat.Cols}");
			mat = Cv2.ImRead(@"d:\downloads\barcodes\barcode.png", ImreadModes.Grayscale);
			Console.WriteLine($"barcode.png : Rows={mat.Rows}, Cols={mat.Cols}");
		}

Output:
barcode.jpg : Rows=0, Cols=0
barcode.png : Rows=206, Cols=500

What did you intend to be?
Is this is a bug in OpenCVSharp or my barcode.jpg is not of correct format?

The barcode.jpg seems not to be JPEG. The file extension is JPEG, but the image header is GIF.
And OpenCV doesn't seem to have a built-in GIF codec.

@shimat
Thanks a lot for your information.


Edited README.md

@Shruti700 We love contributions, but we suggest you try and submit more meaningful PRs by exploring hacktoberfest issues via our website. If you have any problems or need help, please join our Discord community and use the #hacktoberfest channel.


[Contact us] Different sizes of content containers on page

**Environment:**Windows 11 Home Version 22H2 Build	22621.2506
Chrome Версія 118.0.5993.118 (Official build) (64-bit)
Reproducible: always
Build found:
Preconditions

https://zero-waste-staging.onrender.com/ is opened in browser

Steps to reproduce

Go to 'Contact us' page

Actual result
Content containers have different size

Expected result
Content containers have the same size
User story and test case links
E.g.: "User story #
Test case
Labels to be added
"Bug", Priority ("pri:low "), Severity ("severity:low"), Type ("UI").


Improve getting the current context

Summary
Getting the current activity is not done quite correctly.
public static partial class Platform
{
    static Activity currentActivity;

    internal static Activity AppActivity
         => currentActivity
        ?? throw ExeptionHelper.ActivityNotDetected;
}

Permalink
Maybe we could replace this with a IActivityLifecycleCallbacks or the Android.App.Application.Context

@dimonovdd is it easy to reproduce on the sample app?

I have used this technique in the past but if I recall correctly, I had a discussion with @pictos during a code review at XCT that it is prone to performance and memory leaks. When we needed to add it to that project we used the following approach
/// <summary>
/// Gets the <see cref="Context"/>.
/// </summary>
internal static Context Context
{
	get
	{
		var page = Forms.Application.Current.MainPage;
		var renderer = page.GetRenderer();
		return renderer.View.Context ?? throw new NullReferenceException($"{nameof(Context)} cannot be null");
	}
}

This solution won't tightly couple any downstream project to the MainActivity or other Activity objects that they use throughout the lifecycle of their application.

That won't work because this does not take a dependency on Xamarin.Forms. I am going to try and submit a PR for you all to look at that might solve this problem.

Some notes to share after a little bit of research. I don't think what you are doing in this library is necessarily wrong or that there is a better way to solve the problem. You have some trade-offs to consider. First off I don't think you are going to remove any android init code as there is no easy way to get the current activity without setting it like you are.
I just looked into how Xamarin Essentials does this and they created an implementation to the IActivityLifecycleCallbacks to get a complete hook into the lifecycle events as well as the current activity. I think that level of API access isn't necessary for what you are doing in this library. https://github.com/xamarin/Essentials/blob/main/Xamarin.Essentials/Platform/Platform.android.cs
Another option would be using the Android.App.Application.Context which will return the application context. You can't just cast that to an Activity and hope for the best as that will be null. You may be able to make some assumptions with an application context and crawl through the nested activities until you find the correct current Activity, but that can get messy.
The major thing that can be done to improve this is assessing your risk for memory leaks and nulling out the Activity reference when it is no longer needed.

Another option would be using the Android.App.Application.Context which will return the application context

If I remember well this is always null, at least for my tries on XCT.
He's setting the Activity using an Init method, which should never change, but since he opened an Activity to pick some media, that could be the issue. (I'm guessing here)

var page = Forms.Application.Current.MainPage;

@pictos @ahoefling  Hi. Thanks. I would not like to add a dependency on Xamarin.Forms to the plugin
I could use a Android.Content.Context but then I won't be able to call StartActivityForResult method

@ahoefling Could you please describe the API level access problem of the IActivityLifecycleCallbacks in more detail?
@dimonovdd I think you can simply use the Xamarin.Essentials.Platform.CurrentActivity api since you reference Essentials or borrow the ActivityLifecycleContextListener class if you plan to drop the reference.
Moreover, you can use the Activity Result API from AndroidX.Activity in the lifecycle callback listener and avoid the NativeMedia.Platform.OnActivityResult requirement.


RPM packaging

I added a specfile template that enables building alacritty with rpkg, for example in COPR. I would be happy to maintain an inofficial COPR repo that we could mention in README.md for Fedora and EL7/Centos users.
I hope I got all the building and installation steps right, but it seems to work fine in my testing.
Is libEGL a build or a runtime dependency? I was able to build without the package mesa-libEGL-devel . I could add mesa-libEGL (no -dev) as Requires: if it's a runtime dependency.
I had to base this on #2443, as the rpmbuild chroot is not a git repository, and the build failed otherwise.
Unfortunately, I was unable to place the files into extra/linux/rpm or similar, because rpkg expects the macros in the project root.
Lastly, I made some assumptions when generating the RPM package version: I take the output of git describe, replace dashes with dots and drop the leading "v" from the tag name. I didn't want to repeat the crate version in the spec template so it doesn't need to be bumped for every release.
(N.B. git_version is a built-in rpkg macro, but I override it because it expects a specific tagging scheme in the repo).

If this spec file should ever get accepted into the repository it'd be my pleasure to try and get it into the official Fedora repositories (I'm already a package maintainer there so getting it in there would be a matter of sticking to the guidelines and opening an issue on the Fedora Bugzilla instead of the longer process for first time package maintainers where you have to find a sponsor etc. (which speaking from experience can take weeks or even months)) So hit me up once you're done with it maybe :wink:

Awesome, thanks! I will.

Oh and just for your information, if we were to actually add this to Fedora we wouldn't be allowed to use cargo build do download and build all the dependencies but would instead have to specify each dependency as a BuildRequires attribute as fedora like many other Linux distribution s likes to keep control of the source of their packages instead of relying on some external registry

This sounds like a great proposal and I appreciate the help of both of you.
For an external build system it makes some sense to have the .spec.rpkg in our repository, however I'd expect that Fedora has the configurations for all packages stored in their own git repository?
Is that the case @hargoniX? If so, is there any point in adding this to the Alacritty repository too, or should this just be added to the Fedora package repo instead?

Yeah Fedora has a completely self contained build system so adding the spec file to this repository would only make sense if we were to go for a COPR repository as all build files would be stored on Fedora infrastructure anyways.

For the record I have tried packaging rust binary packages before and due to fedoras policy of only having one version of a lib at a time it can actually be pretty hard as for example some sub dependencies might rely on several different versions of popular libraries like lazy_static etc. But I'd definitely give this one a try and suggest the following patches if required

But isn't that only for dynamically-linked libraries? Alacritty only links these libraries when compiled via this spec:
$ ldd /usr/bin/alacritty
	linux-vdso.so.1 (0x00007ffd4edc3000)
	libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f7bb8059000)
	libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f7bb7f9c000)
	libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f7bb7f71000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f7bb7f6b000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f7bb7f66000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f7bb7f5c000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7bb7f39000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7bb7f1f000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f7bb7d59000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f7bb7c13000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f7bb7be5000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f7bb7bdb000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f7bb7bc5000)
	libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f7bb7b8f000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f7bb7b75000)
	libXau.so.6 => /lib64/libXau.so.6 (0x00007f7bb7b6f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7bb87b3000)

These are all packaged.

For an external build system it makes some sense to have the .spec.rpkg in our repository, however I'd expect that Fedora has the configurations for all packages stored in their own git repository?
Is that the case @hargoniX? If so, is there any point in adding this to the Alacritty repository too, or should this just be added to the Fedora package repo instead?

I think there is value in having this now for two reasons:

We can have a unofficial COPR linked in README.md for Fedora users to use as soon as this is merged (or as soon as the next tag, i.e. 0.3.3). Submitting to Fedora proper sounds like a "1.0" thing to do and it might take a while until the project considers that. This would of course be possible when the spec is managed externally, but it's less friction that way.
As the rpmspec has to evolve with the software in terms of library dependencies, and things to install (contributions like shell completions, icons etc.) and possible metadata (Summary, Description and things like that) it should live in the repo IMHO. That way contributors might make the effort to update it when they add something related.

I just rebased the branch on f2b1bfd

After rebasing, the RPM (still) builds: https://copr.fedorainfracloud.org/coprs/pschyska/alacritty/build/928060/

@pschyska to your earlier comment about the libraries, I am talking about the rust libraries here, C is perfectly fine and always works but if we for example consider the parking_lot = "0.7" requirement in alacritty_terminal, I can almost guarantee you that very likely some of the sub dependencies of this project will also use parking_lot however if the version is different that is incompatible with the Fedora idea of libraries as only one version may be available at a time (even if they are source packages only). So if that should be the case, building this with a Fedora packaging specification compliant spec file is impossible without bumping the versions etc.

For the record I have tried packaging rust binary packages before and due to fedoras policy of only having one version of a lib at a time it can actually be pretty hard as for example some sub dependencies might rely on several different versions of popular libraries like lazy_static etc. But I'd definitely give this one a try and suggest the following patches if required.

This will likely be near impossible with any reasonably sized Rust application, including Alacritty. There have been some people helping out greatly with this, however completely removing all duplicates for every release seems unlikely to ever be possible. Rust's version management just isn't really built to force this kind of restriction.
With that in mind, it probably makes sense to move forward with this PR then. We'll get this building as an unofficial package first and hopefully Fedora can figure something out to reliably package Rust applications.

As I wrote I was unable to move the files into extra/linux/, at least not rpkg.macros as the tool expects it in the project root...
I can try something else tomorrow.
I can't build a 0.3.2 manually without modification, as it requires f2b1bfdf37aea62e79b1791127eaf1507edfecd9 to build. The builds will work in COPR after the next tag.
If you just want to test if the package works, you can also check https://copr.fedorainfracloud.org/coprs/pschyska/alacritty/. The latest version there is built from this branch. (sudo dnf copr enable pschyska/alacritty && sudo dnf install alacritty)
The version number encodes the HEAD via git-describe:
<most recent tag>.<commits between tag and HEAD>.<committish>-<package release>.<series>
e.g. <IP_ADDRESS>.g489552d-1.fc30 (package release is hard-coded in the spec and should change when just the spec changes but no other code).
For 0.3.3 the package name will be 0.3.3-1.fc30, etc.
(The COPR repo is not public yet, use at your own risk :-). We could enable automatic builds on every push to master to build "pre-release" packages, but I think these should live in another COPR then, as otherwise people on stable versions would auto-upgrade to non-tagged builds. I'd suggest pschyska/alacritty-git or similar. I will remove the pre-release packages from pschyska/alacritty as soon as I can build a stable 0.3.3.

I can't build a 0.3.2 manually without modification, as it requires f2b1bfd to build. The builds will work in COPR after the next tag.

I'll likely release a release candidate for the next version soon, that should hopefully allow doing a test build, right?

(The COPR repo is not public yet, use at your own risk :-). We could enable automatic builds on every push to master to build "pre-release" packages, but I think these should live in another COPR then, as otherwise people on stable versions would auto-upgrade to non-tagged builds. I'd suggest pschyska/alacritty-git or similar. I will remove the pre-release packages from pschyska/alacritty as soon as I can build a stable 0.3.3.

I'm generally in favor of mainly supporting the last release. If a git release is desired, that can always be added later separately.

As I wrote I was unable to move the files into extra/linux/, at least not rpkg.macros as the tool expects it in the project root...

My bad, seems like I missed that in the original post. That's definitely not optimal, but if there's no way around it that might be fine. Though you said that the only thing required to be in the root is the macros file, right? So could we move this to extra by manually specifying the version? I'm fine with bumping the version myself since I have to do that for several files anyways.

So I've just tried looking at packaging this possible night mare for Fedora according to the standards and it's basically like @chrisduerr predicted....I might ask on the Fedora mailing list for guidance on this but it doesn't seem like any bigger rust project is gonna be packagable according to the standards soon so good luck with your copr repo @pschyska

I'll likely release a release candidate for the next version soon, that should hopefully allow doing a test build, right?

Correct.

So could we move this to extra by manually specifying the version? I'm fine with bumping the version myself since I have to do that for several files anyways.

I'm questioning the value of rpkg right now. It is essentially just a bunch of macros that try to make it easier for git-based projects, but we can't use their version and tagging scheme, as they expect tag names to be name-major-minor (they have a similar way of conveying the HEAD state like git-describe). They generate Changelogs automatically, but they pull them from the commit messages of tags that are made via their scheme. They pre-process the spec.template with bash, although rpm has a sophisticated macro system itself. Honestly, it's probably easier to just commit a plain .spec file and maintain that.
So COPR has 3 build modes: rpkg, tito, and make srpm. Tito is another tool like rpkg, which might be more flexible, but it also seems to expect a release process focused around building rpms, i.e. making tags with the tool itself. The last option just expects a srpm target in the Makefile, and we can do anything we want in there. As we already have a Makefile it's probably better to commit just the spec file and add the srpm target. Then we can do anything we want without tool constraints :-).
I also saw that Fedora has a set of macros called rust-packaging, maybe there is something we can use to use cargo metadata instead of hard coding things into the specfile. I'll invest an hour or two to check that out.

Honestly, it's probably easier to just commit a plain .spec file and maintain that.

Would you be willing to contribute one? I'm fine with maintaining it if it just requires updating some version number, however I don't have any Fedora system to write or test it, so help in that area would be much appreciated.
I personally don't really care either way, since I'm not really familiar with Fedora build things, but going closer to the target by removing useless abstractions is usually a good thing.

Would you be willing to contribute one?

Yes, of course! I'm working on it.  Or mesa-libEGL-dev?
I have mesa-libEGL on my system and I can't remove it, so I can't really check if alacritty would work without it. There was a note in the installation instruction that nvidia-users might want it. My machine has an intel chip but I still have it on a default install. I'm thinking it's probably correct to add it as Requires:?
I'm pretty sure it's not a BuildRequires, and we don't need mesa-libEGL-dev to build, as I never had that. Unless alacritty would build differently with mesa-libEGL-dev installed, but I didn't find a reference in the project that would indicate that.

@pschyska EGL is required when running Wayland. On X11 it's just a fallback and GLX is used by defaualt.
Not sure how Fedora differentiates between Wayland/X11, but that probably means it should always be required.

But that means it's not a direct dependency, but a dependency on running Wayland at all if I understand correctly? Cursory search on the internet seems to imply that the proprietary nvidia drivers install their own conflicting version of this library. If that is true, and we depend on it, nvidia user wouldn't be able to install alacritty.
mesa-libEGL is required by libglvnd which is required by gnome-session, etc.
I expect it to be available wherever any wayland compositor is installed, and we should not depend on it.

I went deep in the rabbit hole of trying to make the defined version more flexible, and derive it from the source tree (i.e. parsing cargo metadata), but failed. I can only control the building of the SRPM to some extend in COPR, and the version number generation logic failed during the build of the actual RPM. I have some other ideas but for now I think it's fine to leave the version hardcoded.
It needs to be bumped when a new Version is tagged and can't contain -. Fedora has a notion of pre-release packages which we probably should obey.
For tagging 0.3.3-rc1 I recommend the following:
Version:       0.3.2
Release:       0.1%{?dist}

0.3.3-rc2 would be
Version:       0.3.2
Release:       0.1%{?dist}

I'm personally disappointed because I planned to set up a private COPR that builds every revision of master for testing, and that's not easily possible now, but I might figure it out eventually and open a new PR for that :-).
As for the file paths, there is a .copr now in the project root although the spec file could move. If we use the third build options, we would have a .tito in the project root, so there doesn't seem a way around it...

But that means it's not a direct dependency, but a dependency on running Wayland at all if I understand correctly? Cursory search on the internet seems to imply that the proprietary nvidia drivers install their own conflicting version of this library. If that is true, and we depend on it, nvidia user wouldn't be able to install alacritty.

Alacritty just requires any EGL library, it doesn't have to be mesa's. I don't know how this works in Fedora, but there's usually standards about what dependencies need to be included and which can be assumed to exist (like the linux kernel for example).
I know that with Archlinux, there exists a concept of a 'provider' for certain things. So both the proprietary nvidia driver and mesa provide 'opengl-dri', so a package would only have to depend on 'opengl-dri' and the user could then decide which package he wants to install that provides this.
Generally it's not a direct dependency, in the way that not every Alacritty instance requires it. However every Alacritty instance requires some form of GPU drivers for graphics to work and on linux either a working X11 or Wayland server.
You can take a look at the Archlinux package dependencies as a reference, though I can't say anything about Fedora standards:
https://www.archlinux.org/packages/community/x86_64/alacritty/

As for the file paths, there is a .copr now in the project root although the spec file could move. If we use the third build options, we would have a .tito in the project root, so there doesn't seem a way around it...

I think that should be fine. There's also a .travis.yml and similar stuff, for things that require to work based on the directory root.
However, I am curious how COPR polls this. Does it require manual interaction to build or will it just build whenever the file is changed? Usually only tagged versions are actual releases, so even though it shouldn't matter, one might not want to directly build on every change to master.

Generally it's not a direct dependency, in the way that not every Alacritty instance requires it. However every Alacritty instance requires some form of GPU drivers for graphics to work and on linux either a working X11 or Wayland server.

I don't know for sure how to handle that. I would rather leave the dependency out than to run with it and possible break the package for nvidia users (as in: making it not installable). I would expect everyone trying to run alacritty to have a working graphical environment though 😏
I'll try figure it out and amend the dependencies in a follow-up PR.

You can take a look at the Archlinux package dependencies as a reference, though I can't say anything about Fedora standards:
https://www.archlinux.org/packages/community/x86_64/alacritty/

I don't see any dependency on any GL libs, and/or wayland libs there. Just some supplemental X input libs.
Am I blind? Unless libEGL is pulled in by one of these...

However, I am curious how COPR polls this. Does it require manual interaction to build or will it just build whenever the file is changed? Usually only tagged versions are actual releases, so even though it shouldn't matter, one might not want to directly build on every change to master.

They support webhooks, but you'd need custom scripts to unpack the json to figure out if the webhook is about a newly-pushed HEAD in refs/tags, for example. By default they just trigger a build everytime the webhook is invoced, and you can only specify a single commitish to build like master. AFAICS they don't support something like build refs/tags/* ☹.
As soon as 0.3.3(-rc) is tagged, I would push the button and manually insert refs/tags/v0.3.3-rc1 into the form and that version would be built. For now. And then remove the private flag from the COPR and send a PR on README.md that mentions how to install it from there. Hey, it's a start, right?

I don't see any dependency on any GL libs, and/or wayland libs there. Just some supplemental X input libs.
Am I blind? Unless libEGL is pulled in by one of these...

That's the point I was trying to make. Archlinux does not add these as dependencies.

They support webhooks, but you'd need custom scripts to unpack the json to figure out if the webhook is about a newly-pushed HEAD in refs/tags, for example. By default they just trigger a build everytime the webhook is invoked, and you can only specify a single commitish to build like master. AFAICS they don't support something like build refs/tags/* frowning_face. It would also be possible to ping COPR from travis, or something similar.

It should be fine for now, though that's something we might want to keep in mind. Triggering from travis sounds like a decent idea.

That's the point I was trying to make. Archlinux does not add these as dependencies.

Alright sorry, I misunderstood that.
Let me know if you think there is something else to do before this can be merged. Thanks!

@pschyska I've got another question with the pre-release stuff. Will people have to opt-into that or would 3.3/0.1 automatically get installed for someone on 3.2/1.0?

I doubt it, but I will test tomorrow.

@chrisduerr I have researched Fedora versioning guidelines, and how rpm (or rather dnf) will behave.
For reference: Versioning guidelines, Examples.
The traditional way to release a RC would be to "abuse" the Release: tag to signify that this is a pre-release, e.g.:

Alacritty
Version
Release
RPM

0.3.3-beta1
0.3.3
0.1.beta1
0.3.3-0.1.beta1

0.3.3-rc1
0.3.3
0.2.rc1
0.3.3-0.2.rc1

0.3.3-rc2
0.3.3
0.3.rc2
0.3.3-0.3.rc2

0.3.3
0.3.3
1
0.3.3-1

However, I don't like that, as the 0.N in Release has to be manually bumped every time, and for that you need to know what the last version used, and there is no relation of the integer to the upstream version.
There is a new proposal that allows the use of the ~ in the Version: which makes it always sort lower than anything else with the same prefix. (See this discussion).
In that scheme, the Release: would be used for versions where no code except the specfile itself changed (like it was originally intended, AFAICS). So it would normally stay at Release: 1 for all versions. E.g:

Alacritty
Version
Release
RPM

0.3.3~beta1
0.3.3~beta1
1
0.3.3~beta1-1

0.3.3-rc1
0.3.3-rc1
1
0.3.3-rc1-1

0.3.3-rc2
0.3.3-rc2
1
0.3.3-rc2-1

0.3.3
0.3.3
1
0.3.3-1

This is much more sane IMHO and I think we should use that scheme. There is a pathological case where the "prerelease name" is not alphabetically sorting. Imagine there is now a release called "pre" which should come after "rc2". In that case its Version must be changed from the upstream name to make it sort again, i.e. by introducing a 1. prefix:

Alacritty
Version
Release
RPM

0.3.3~beta1
0.3.3~beta1
1
0.3.3~beta1-1

0.3.3-rc1
0.3.3-rc1
1
0.3.3-rc1-1

0.3.3-rc2
0.3.3-rc2
1
0.3.3-rc2-1

0.3.3-pre
0.3.3-1.pre
1
0.3.3-1.pre-1

0.3.3
0.3.3
1
0.3.3-1

So it's getting ugly again (package version diverging from upstream), but at least this situation goes away when 0.3.3 is released and is only necessary for this one version. I also don't expect this to ever happen in practice :smirk:
The bad news is that dnf would the upgrade from 0.3.2 to 0.3.3-rc1 regardless of the way we use. So that also means I must have separate release and prerelease COPRs.
tldr; I'm updating my recommendation on how to tag the upcoming 0.3.3-rc1:
Version:       0.3.3~rc1
Release:       1%{?dist}

@hargoniX Can you chime in if that makes sense, as you are probably more experienced with the guidelines than I am?

The bad news is that dnf would the upgrade from 0.3.2 to 0.3.3-rc1 regardless of the way we use. So that also means I must have separate release and prerelease COPRs.

In that case it seems like the best solution is to just not bump the fedora copr build for RCs at all and instead just update it when versions are released.

In that case it seems like the best solution is to just not bump the fedora copr build for RCs at all and instead just update it when versions are released.

But then I get no chance to test if packages will build correctly for RC's, which I'd like to do. If a packaging issue comes up (i.e. new dependency), I would only be able to correct it for the next release tag...
Please just bump the version in specfile like I described when you tag RC1, I will deal with it. We don't have to mention the COPR repo containing only RC's anywhere, but it would make my life much easier.
pschyska/alacritty will always only contain releases in any case.
Cheers

But, I would argue will still should offer pschyska/alacritty-pre as a COPR so we don't lose Fedora users that don't want to manually build as potential prerelease testers.

Okay, so for version 0.3.3 I will tag a pre-release since none exists yet, then for future releases we can just skip the pre-release and go straight to the versioned releases.
I'm not concerned with pre-releases at this point since people can just build from source, that shouldn't be much of a problem for people interested in testing especially since Rust projects are so straight-forward to build.
If I understand everything correctly, COPR will be watching only the master branch and build whenever I change the version in the spec file, right?

If I understand everything correctly, COPR will be watching only the master branch and build whenever I change the version in the spec file, right?

No, I will trigger the builds manually for now. You can ping me when you make a new git tag, but I will regularly check anyways.

Okay, so for version 0.3.3 I will tag a pre-release since none exists yet, then for future releases we can just skip the pre-release and go straight to the versioned releases.

Alright, let's say whenever you tag a RC, you bump the specfile accordingly. If you are not tagging anything in git anyways, there is no need to build RC rpms, obviously. I just saw that there used to be RC's, and you mentioned it, so I thought you might want to use prereleases more.
I'm fine either way, I just want to avoid that there is a 0.3.3-rc1 tagged but the specfile still says 0.3.2, and then someone wants a 0.3.3~rc1 rpm package to test something and I can't build it without hand-patching the specfile.

I'm fine either way, I just want to avoid that there is a 0.3.3-rc1 tagged but the specfile still says 0.3.2, and then someone wants a 0.3.3~rc1 rpm package to test something and I can't build it without hand-patching the specfile.

That's exactly what's going to happen though. If a RC is going to overwrite the existing release, I'm not going to tag RCs for the Fedora build. RCs should not get published to package repositories. If you want to test a RC, you can always build from source.
It completely ruins the point of RCs when everyone gets upgraded to them, since that just makes them equivalent to normal releases and everything breaks for everyone. It's meant as a best-effort to catch some bugs before releasing to the world.

That's exactly what's going to happen though. If a RC is going to overwrite the existing release, I'm not going to tag RCs for the Fedora build. RCs should not get published to package repositories. If you want to test a RC, you can always build from source.
It completely ruins the point of RCs when everyone gets upgraded to them, since that just makes them equivalent to normal releases and everything breaks for everyone. It's meant as a best-effort to catch some bugs before releasing to the world.

But that's not going to happen, as it's in a different repository. Every COPR has their own rpm repo, so if you never enabled, let's say pschyska/alacritty-pre, in addition to pschyska/alacritty you would not get pre-releases.
(If you are like me, you would have enabled it and get the RC's as soon as they come out.
I don't mind occassional breakage as it's easy to recover, and I like when I'm able to report meaningful bugs if I can.)
But again, enabling alacritty-pre would be a deliberate choice, with a warning attached.

The bad news is that dnf would the upgrade from 0.3.2 to 0.3.3-rc1 regardless of the way we use. So that also means I must have separate release and prerelease COPRs.

Based on this I thought that would mean this wouldn't be a reasonable approach, but if you're willing to maintain them separately and it's an opt-in for the pre-releases, that's fine by me.
I just don't want people that install the regular one to suddenly run RCs. But it sounds like we should be good to go.

Unsurprisingly, the package still built with the bumped rust dependency :smile:
Was there anything else?

@pschyska I think everything should be tagged properly now for 0.3.3-rc1, let me know if there are any issues.

@chrisduerr For some reason, my e-mail reply didn't get posted. I went ahead and create 2 public repos (stable and testing). You can check them out here:
alacritty
alacritty-testing
I worded alacritty-testing differently, and removed the detailed installation instructions to dissuade users that might not want to test pre-releases from using that one, I hope that works for you :smirk:.
The prerelease build is currently running. When you tag 0.3.3 stable, I will send you a pull request on README.md.

@pschyska Version 0.3.3 is released now, hopefully everything should work out.

@chrisduerr Thanks, the build was successful: https://copr.fedorainfracloud.org/coprs/pschyska/alacritty/build/936407/
I'll do a quick check and then send a PR for README.md.


[Telink]: BLE commissioning (docker part)

Problem
Currently Zephyr OS does not contain implemented Telink BLE controller yet.
So that, BLE functionality for Matter project is implemented with Telink BLE SDK.
This PR contains update of docker image with Zephyr that adapt Telink Radio module work in
both BLE and Thread modes (not concurrently).
The PR is closely related to: https://github.com/project-chip/connectedhomeip/pull/15723
Change overview
Updates in Telink docker image that contains late Zephyr source code with modifications in Telink radio driver
Testing
Tested manually.
Steps:

Build image
Run docker
Check if Telink lighting-app example able to be built successfully

Hi @Damian-Nordic, @woody-apple
As I see doxygen and infenion docker images have some troubles to be built. Could you tip me, what shell I do regarding to this?
Regards, Alex

Infineon was fixed in 0.57 just today. For doxygen I will have to review. Generally when image A is updated, I merge even if some other image fails since they are independent. Unfortunately docker images depend on 3rd party things that change (e.g. linux package versions or various download URLs)

@andy31415
doxygen and infineon images are fine now. But each time after rebase I face non stable issues with other CI jobs, like:

Build example - Linux Standalone / Linux Standalone (pull_request) - Reason: timeout
Builds / Build on Linux (fake, gcc_release, clang, mbedtls, simulated) (pull_request) - Reason: cancellation
Builds / Build on Darwin (clang, python_lib, simulated) (pull_request)

It seems that this jobs are not stable. May we do some with it?
Regards,
Alex