Fix unzip binary files incorrect

Coverage remained the same at 100.0% when pulling 8cf317d82624ba396db8ef637391904a01e5f688 on zbinlin:fix-binary-file into 4c01544d7c7176976bb60a32a14a4ecf7a42e0cf on peerigon:master.

Gonna merge your PR @zbinlin! Thanks for your contribution and I'm very very sorry for the ~1 month delay 😢


New navigationbar/menu options

While I very much love your theme, it's a shame it's ruined by such a boring theme - I wish there was the option to choose between more modern navbar options, like the one Grayscale has: https://startbootstrap.com/template-overviews/grayscale/

Thanks for the feedback! I'll look into adding another optional header style for those that don't like the default one, I appreciate the feedback.


The Azure App Insights key is not a valid GUID

Tried to deploy the app for a customer today & received the following error similar to the ones being discussed.
Generated new GUID & still the same error message while validating the Azure App Insights Key. Says it is not a valid GUID.
Raw Error:
{  "code": "InvalidTemplateDeployment",  "details": [    {      "details": [        {          "code": "InvalidBotData",          "target": "TeamsCommunicator-author",          "message": "The Azure App Insights key is not a valid GUID"        },        {          "code": "InvalidBotData",          "target": "TeamsCommunicator",          "message": "The Azure App Insights key is not a valid GUID"        }      ]    }  ],  "message": "The template deployment 'Microsoft.Template-20230301122158' is not valid according to the validation procedure. The tracking id is '178caf13-3f5b-47d6-874a-c0d5eda0d90f'. See inner errors for details."}

Hi @allengeorgek ,
Thanks for raising the issue. We are working on this issue already. Duplicate to [975) (https://github.com/OfficeDev/microsoft-teams-apps-company-communicator/issues/975)

hi @gsv022 - Do we have any ETA on this? Customer CXO team is actively involved in the deployment of this app & hence very critical to have this resolved soon.

@allengeorgek , We are prioritizing this issue as our highest concern, and we have tentatively identified the problem. Currently, we are testing a potential solution, and we will confirm once we have found a working fix.

Hi @allengeorgek,
We identified that the issue is not specific to the company communicator but is due to a recent update in either Bot Services or Azure template custom validation. The update is preventing the creation of a reference of App Insights Instrument key to the Microsoft Bot Service configuration. This change is impacting other templates and repositories that are dependent on it, including company communicator.
We have identified a possible workaround and are currently testing it with the highest priority. As soon as testing is complete, we will share the steps to unblock the deployment. Thank you for your patience and understanding as we work to resolve this issue.

Hi @allengeorgek ,

It is identified that the issue is not specific to the company communicator but is evident that there is an issue with Azure ARM resources functionality.
We have updated the Deploy to Azure link in 2nd step of the CC Deployment Guide. The earlier faced issue "The Azure App Insights key is not a valid GUID" is now resolved and deployment is working as expected.
Please try deploying the Company communicator app and let us know if you face any further issues.
If the deployment is failing due to role assignments, please refer to the Troubleshooting Guide.

@allengeorgek , Please let us know the status if the issue persists. Otherwise we are good to close out the issue.

@allengeorgek, We are closing this request as we have provided the inputs for the query raised. If you face any issue with company communicator please raise a new issue for further assistance.


Should module settings be deleted when projects are deleted?

I believe a cron job removes project metadata (like fields) from the database a month after the project is marked as deleted in the UI.  We should run this plan by @taylorr4, but we should likely modify this cron job to delete module settings as well, including edocs.  This should likely be implemented in a method in the module framework's ExternalModules class, with a single line call to it from the cron job in REDCap core.
Thanks to @scottjpearson for reporting this!

@mmcev106, module settings get deleted automatically when a project is deleted (i.e., after the 30 day period in the "recycle bin"). This is done via the project_id foreign key in redcap_external_module_settings, which deletes it from the table cascading from when the project is deleted from redcap_projects.

Awesome.  Thanks @taylorr4!


Add OPUS support

Right now the MicrophoneInputStream only encodes raw data, which can get heavy for mobile use cases. Adding OPUS support will help keep things light

@Hsaylor I would start by looking at what they did

Merged with #11


Ibex bitstream is not working on hardware after parsing ram_1p.sv.

There is no error on parsing ram_1p.sv file (in both yosys and vivado), but generated bitstream is not working on hardware.

I couldn't find a way of setting SRAMInitFile when parsing file using Surelog, without this, Surelog removes parts of the code, when this parameter is empty: https://github.com/alainmarcel/Surelog/issues/937


esp32c3 can not control gpio 11 (IDFGH-13596)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
Chip: esp32c3 FN4
I set gpio11 to switch the level once every second, but in the end I only got a voltage of about 3v3 to 3v0.
I think the code is ok because I changed 11 to 21 (21 is connected to an led) and everything works fine.
BTW: On the chip, gpio11 is the VDD_SPI identifier.
Code:
gpio_config_t cfg;
cfg.mode = GPIO_MODE_OUTPUT;
cfg.pull_up_en = GPIO_PULLUP_ENABLE;
cfg.pull_down_en = GPIO_PULLDOWN_ENABLE;
cfg.pin_bit_mask = 1ull << GPIO_NUM_11;
gpio_config(&cfg);

while (1) {
  s_led_state = !s_led_state;
  gpio_set_level(GPIO_NUM_11, s_led_state);
  vTaskDelay(CONFIG_BLINK_PERIOD / portTICK_PERIOD_MS);
}

GPIO11 of ESP32S3 is assigned to output power supply for flash.
Unfortunately, the following commands are not supported by ESP32C3.
espefuse.py set_flash_voltage OFF

See here.
https://docs.espressif.com/projects/esptool/en/latest/esp32c3/espefuse/set-flash-voltage-cmd.html

GPIO11 of ESP32C3 is assigned to output power supply for flash.
Unfortunately, the following commands are not supported by ESP32C3.
espefuse.py set_flash_voltage OFF

See here. https://docs.espressif.com/projects/esptool/en/latest/esp32c3/espefuse/set-flash-voltage-cmd.html

Humm..I have tried this command befor I see ur response:
espefuse.py -p /dev/ttyACM0 burn_efuse VDD_SPI_AS_GPIO 1

And now, I can not flash and run on this chip.
What do u recommend?

What do u recommend?

Unfortunately I can't think of any


Ability to serialize / deserialize boolean properties as numeric values in json

Feature description
I have a boolean property that I would like to serialize/deserialize to json as a numeric value 0 or 1. I believe this typically could be done by annotating the property with @JsonFormat(shape=JsonFormat.Shape.Number). As documented micronaut doesn't not support the shape property for JsonFormat and attempts to use it result in the following error:
Annotation @JsonFormat specifies attribute 'shape'. Currently supported attributes include: [timezone, pattern, locale, lenient]

Are there any plans to support this?

probably doable yeah

I don't have a feel for how big of an undertaking this would be. If this seems like something that would be a good starter task, and someone is willing to point me in the right direction, I'd be willing to take a stab at a solution.

step 1 is disable the compile time check in JsonFormatMapper by modifying getSupportedMemberNames
Then I guess BooleanSerde would need to be modified to override createSpecific for serialization / deserialization with a specific customised serialised to handle the shape

The other solution would be detecting it in the compilation time and and setting a custom serializer/deserializer interface ShapeDeserializer / interface ShapeSerializer + add implementation which would use createSpecific and some logic to do the convertion

that would likely be more efficient yes


Hence I disable it.


No reference in the code

Did you copy the code from my repository https://github.com/usimarit/TiramisuASR?
I looked into the code and I see it look like the code I wrote.
It would be nice if you could write references to where you learn and take source code or any kind of knowledge involving in this repo. Other authors would appreciate it.

Sorry, I didn't add reference in time.
Because the code is still in the development stage, and there will be additions, deletions, etc.
The expectation is to add relevant references after debugging and functional verification.
I will add reference in soon.

Alright, I just want to remind you about this :smiley:


backports for v3.26: fix panic due to nil route dst

Description

Related issues/PRs

https://github.com/projectcalico/calico/issues/7645
Todos

[ ] Tests
[ ] Documentation
[ ] Release note

Release Note

TBD

Reminder for the reviewer
Make sure that this PR has the correct labels and milestone set.
Every PR needs one docs-* label.

docs-pr-required: This change requires a change to the documentation that has not been completed yet.
docs-completed: This change has all necessary documentation completed.
docs-not-required: This change has no user-facing impact and requires no docs.

Every PR needs one release-note-* label.

release-note-required: This PR has user-facing changes. Most PRs should have this label.
release-note-not-required: This PR has no user-facing changes.

Other optional labels:

cherry-pick-candidate: This PR should be cherry-picked to an earlier release. For bug fixes only.
needs-operator-pr: This PR is related to install and requires a corresponding change to the operator.

/sem-approve


Fix comment box not showing on PR commit replies

Fixes #5237
The form that gets revealed when clicking on the "Reply" button mentioned in #5237, and the button, do not share the same parent. The button ends up getting wrapped in a link which causes this issue.
I have no idea how or why this worked on the English translation though. Didn't dig in that deep. :)

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@c8b4c7a). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #5239   +/-   ##
=========================================
  Coverage          ?   37.48%
=========================================
  Files             ?      310
  Lines             ?    45923
  Branches          ?        0
=========================================
  Hits              ?    17215
  Misses            ?    26234
  Partials          ?     2474

Continue to review full report at Codecov.

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

Hmm.. it's very interesting in the English translation the comment button appears in the following structure (This is presumably the case for every translation that works):

...

    <button class="comment-form-reply ui green labeled icon tiny button">...</button>
    <form class="ui form hide comment-form comment-form-reply" action="..." method="post">...</form>

However, in the Spanish translation it becomes:

...

        <button class="comment-form-reply ui green labeled icon tiny button">...</button>

    <form class="ui form hide comment-form comment-form-reply" action="..." method="post">...</form>

OK I think that the locale-es_ES.ini file has a problem. There are likely other problems in that file too.
line 459:
...
issues.commented_at=`comentado <a href="#%s"> %s`
...

is the cause of this issue. The backtick (\``) before the means that the` is never closed.

Nice find! This might not be the best fix then. It works but it might not be the most efficient.

If you guys are fine with it, I can use this PR to make those changes. Unless @zeripath you would like to, or if another PR should be raised for this issue.

The translations should be done via crowdin, as otherwise they will be overwritten by crowdin.

line 795: auths.tip.facebook also needs adjustment as it has an open double-quote.

Closing as translation files have been updated.


S-test differences for same test catalog

Using the Helmstetter example gridded forecasts and one of my own, I tried to compare S-test results and was surprised that the Helmstetter examples did poorly. This seems to be related to the spatial filtering step and the region associated with the test catalog, even when the regions have the same midpoints and the evaluation catalog contains the same events.
Comparing the midpoints for the two regions with np.testing.assert_allclose flags that they are different:

Not equal to tolerance rtol=1e-07, atol=0
Mismatched elements: 15287 / 15364 (99.5%)
Max absolute difference: 11.600000000000009
Max relative difference: 0.34850863422291994
x: array([[-125.35,   40.15],
[-125.35,   40.25],
[-125.35,   40.35],...
y: array([[-117.15,   31.55],
[-117.05,   31.55],
[-116.95,   31.55],...

I sorted the midpoint xs and ys and they are identical. Essentially my test forecasts and the example have different regions, though the sorted midpoints are the same. The filtered catalogs for the evaluation are also identical, but the s-tests results are very different.

Do the regions maybe need some sorting somewhere for the spatial test?
My test forecast:
CSEP_test_forecast.txt

in theory the regions should not need sorted for the spatial test. the test result for the shaded gray region seems to be the s-test result for the helmstetter model, same as the example. can you explain in a bit more detail how you created the bottom evaluation?

Yes, my problem is that I was trying to compare forecasts with different order of grid cells using one catalog, which I now understand I should not do! I had assumed that the region would be the same if the grid cells were the same and so it would be suitable to use one test catalog to compare forecasts. I was attempting to compare my own forecasts with the Helmstetter example and then used the Helmstetter example to illustrate my problem here, since the example on the website shows me what the result should be vs what I was getting. Sorry, I was not clear at all!
The bottom evaluation uses the same catalog as the example but filtered with the test_forecast.region from my test_forecast rather than the forecast.region in the example code, so it is the same catalog for the evaluation but the region is set up differently.
So I was just doing this in my example above:
catalog = csep.query_comcat(forecast.start_time, forecast.end_time,
                            min_magnitude=forecast.min_magnitude)'

cat1 = catalog.filter_spatial(forecast.region)
cat2 = catalog.filter_spatial(test_forecast.region)

spatial_test_result = poisson.spatial_test(forecast, cat1)
spatial_test_result2 = poisson.spatial_test(forecast, cat2)

When I should have made a separate catalog to evaluate my test forecasts and used the original filtered catalog for the Helmstetter. It wasn't clear to me that this would result in major differences in the s-test given that the actual catalog I am using for the evaluation is exactly the same, this is because the evaluation uses the region information, right? So if it's not ordered in the same way, I'll get a bad result. I see now, thank you.

that is a reasonable assumption, i'm going to leave this issue open and make a couple changes that should make this process more straightforward. thanks for sharing some more information about this.
specifically, the function filter_spatial updates the state of the catalog meaning that the orignal catalog is changed after you call this function. this causes an issue when you call the function again. you can check the event count of catalog after the first filter_spatial call, to see what i'm talking about.
i'm going to add an option called in_place to the function that produces a new catalog object and will allow you to use your code as written. i think this way makes more sense to me, and is consistent with the way the filter function works.
in the mean time, you can
import copy

catalog = csep.query_comcat(forecast.start_time, forecast.end_time,
                            min_magnitude=forecast.min_magnitude)

copy_catalog = copy.deepcopy(catalog)

cat1 = catalog....
cat2 = copy_catalog....

ill post here when ive made this modification.


Rekumar/issue12

changes = moving the check for task_id into get_task, reformatting with black.

only error is with version control, will address later


Remove var_dump call

This change is

Coverage: 94.108% (-0.01%) from 94.118% when pulling 562a46451af2b8890bff5f6fa38271617c3d554d on gharlan:patch-2 into abf042c8afe4bb6927f00b5ac14b089a295284d9 on voku:master.

Thanks. 👍😊
(Maybe I shouldn't have realeased it after midnight and better gone to bed.)


Not working at all. Immediate blows the 1117

Has anyone actually built this?
As soon as i give it power it blows the 1117. When i power the Atmega just from 5v it works. Double, triple and 5x checked component placement and its all per v1.1

Found the issue, apparently the sot89 casings have many different pin configurations for LDO.
And the main mosfet the IRLR8726TRPBF was bad and might not be optimal.
So make sure you get the correct SOT-89 LDO and an alternate to the IRLR8726TRPBF that works is AOD4184A.


centos7-els seems to cause failed upgrade

I just tried 1.3.2 on a system that had been updated to Plesk .62 with the Plesk ELS repos enabled and all updates, including those from the ELS repo, installed. I was happy to do so because the changelog mentions that Plesk ELS repos and now dealt with.
All went well until somewhere close to the last hurdle, at "Do: adopting repositories" when serious conflicts occurred because those repos were seemingly not disabled, and the script aborted. [Or maybe the disabling of the repos wasn't supposed to happen just yet, and the problem was actually caused by the fact that dnf could not download repomod.xml from any of them for some reason (see log)?]
e.g.
INFO - Problem 1: cannot install the best update candidate for package bind-32:9.11.36-14.el8_10.x86_64
INFO - - nothing provides policycoreutils-python needed by bind-33:9.11.4-26.P2.el7_9.15.tuxcare.els1.x86_64 from centos7-els
INFO - - nothing provides python-ply needed by bind-33:9.11.4-26.P2.el7_9.15.tuxcare.els1.x86_64 from centos7-els

The full feedback file is attached, but essentially at this stage the main things that go wrong can be seen in failure-log.txt
There are also issues shown in the log with icinga and grafana packages which are nothing to do with Plesk, but although those are my fault for not thinking about them, I don't think they are the direct cause of the failure - but of course I could be wrong.
At the point things failed, several repos relating to Centos 7 were still there and still enabled, despite the fact that we seem to be running Alma 8 and all the alma repos seem to be installed and enabled:
centos7-els.repo
centos7-els-rollout.repo
CentOS-SCLo-scl.repo
CentOS-SCLo-scl-rh.repo
I wasn't aware of those "scl" repos before I started the upgrade. I don't mean that they got added during the upgrade, I mean I didn't think to look to see what might be there and didn't take them into account before I started.
Anyway, I've restored from backup and all is well, but we are back on C7, obviously.
failure-log.txt
centos2alma_feedback.zip

I have repeated this with a "clean" Centos 7 system with Plesk ELS but with no icinga/grafana and no Centos-SCLo. Just the normal, expected repos and nothing extra.
Unfortunately I got the same result - upgrade failure due to conflicts (e.g. bind) when adapting repos.
Here's the feedback file for that one:
centos2alma_feedback2.zip

And finally....
I repeated the upgrade again on the second ("clean") system that had Plesk ELS, but this time I deleted the plesk-els.repo and plesk-els-rollout.repo before running centos2alma.
Now all went well, and the upgrade completed as expected.
Some oddities I noticed were:
The "screen" utility had been removed and not reinstalled.
The following el7 packages remained:
btrfs-progs.x86_64                          4.9.1-1.el7                                   @System
els-define.x86_64                           1-1.0.4.el7                                   @System
kernel.x86_64                               3.10.0-1160.118.1.el7                         @System
kernel.x86_64                               3.10.0-1160.119.1.el7                         @System
libdb4.x86_64                               4.8.30-13.el7                                 @System
yum-plugin-fastestmirror.noarch             1.1.31-54.el7_8

els-define is part of the Plesk els thing. It says it is "CentOS Server els-release file".
I'm not sure why it left btrfs-progs, libdb4 or yum-plugin-fastestmirror.
I've removed fastestmirror and els-define, but I'm not sure about the libdb4 or btrfsprogs. They don't seem to have dependencies but maybe there was a reason for them to have remained.
Anyway, in conclusion, it would appear that 1.3.2 does not correctly handle systems with Plesk ELS installed, at least on the two systems I've now tried it on.
I'm not sure if it also can't handle systems with Centos-SClo repos either, but I've not tested that properly.
The workaround for ELS is to delete the centos7-els.repo and centos7-els-rollout.repo before running centos2linux, then removing the els-define package after the upgrade is complete.
With increasing numbers of people in panic mode, and with Plesk ELS being auto-installed on a lot of systems from now on, I strongly hope that this/these issue will get resolved quickly.

We've made some configuration changes on our service endpoints. So now the same 1.3.2 script version should work correctly.
However, there is a prerequisite:

either wait for 1 day before trying to run the script;
or run plesk daily UpgradeExtensions manually on the server before running the script.

In both cases you should see "TuxCare Extended Lifecycle Support" (tuxcare-els) in your Plesk extensions list as a result.
Once you do, it should be safe to convert to AlmaLinux 8.
Please notify us if this helps you. Sorry for the previous inconvenience.

That's very good news. Thank you. I will give it a day or so and see if it appears.

@farisc1 , did you have a chance to check this?

In progress right now.....

OK. It does now work perfectly. Thank you.
Starting point:
Centos 7, Plesk .62 Update 1, Plesk ELS installed, Plesk ELS showing in My Extensions, all OS and Plesk packages up to date,  centos7 yum repo files changed to vault instead of mirror, mariadb 10.5 yum repo exists and enabled. epel (7) repo exists and enabled.
Stage 1: 9 mins
Then about 27 minutes for the rest to complete to the point of final reboot and everything working as it was before, except that we  are now on Alma 8.
After final reboot, there is still /root/tmp_leapp_py3/leapp3 left over.
The following el7 packages remain:
btrfs-progs.x86_64                          4.9.1-1.el7                                   @System
kernel.x86_64                               3.10.0-1160.118.1.el7                         @System
kernel.x86_64                               3.10.0-1160.119.1.el7                         @System
libdb4.x86_64                               4.8.30-13.el7                                 @System
yum-plugin-fastestmirror.noarch             1.1.31-54.el7_8                               @System
"screen" utility is removed for some reason.
MOTD is shown twice when logging via ssh but not via console.
I think one of the duplications comes from .plesk_banner which seems to be a new thing?
Speaking of MOTD, I think maybe it would be useful for MOTD tell you to install the NTP Timesync extension.
Everything in /etc/yum.repos.d/ seems to have been dealt with correctly.
I can't find the leapp logs that were referred to by the script during the upgrade process. I was looking for what it thought were the el7 packages left over, which was mentioned as being written to a leapp logfile that I can't seem to find at all.
But overall, we are now at a 100% success to all intents and purposes. Thank you for your excellent work. I hope no new issues appear in the next few days, as we have a full update of a live system to do late on the 9th/early on the 10th (UTC).
PLEASE start work on CloudLinux 8 to CloudLinux 9 next :-) Yes, 8 to 9.

Thank you for detailed report!


Shift Sec HUD To The Right Side

About the PR
Makes the Sec HUD job icons prefer the right side.
Why
The chat indicator would constantly get overlapped by the job icons and make it hard to tell whenever someone was typing, which was quite annoying.
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame.

Changelog
:cl:

fix: Fixed Sec HUD icons overlapping with speech indicators.

typing indicators as status icons when


Some way to ban suggestors?

If more than twice suggested rejected prediction?
Get list of users and how much they suggested rejected predictions?
Rejecting reason? For example, extra button "reject as inappropriate"
A message to the person that suggested rejected prediction with a warning "N more inaproppropriate suggestion and you will be banned" if it was rejected as inappropriate

button "reject as inappropriate" already done

Rejecting reason will be done in #6


Unison doesn't work on FM

Either unison wasn't meant to be with FM or you made an error in coding.

I already fixed this for 1.5 so it won't be an issue soon

Pasting FM instruments with custom unison resets to the default 'none' unison. This is a bug related to this.

Unison wasn't ever meant to be on FM, I made a mistake

It also doesn't work on supersaws

This issue was caused by a misspelling I made in the code, I never actually programmed unison into those instruments

Maybe you could keep the unison in both instruments?

Supersaw and FM? The code literally doesn't exist for it to even do anything so keeping the dropdown doesn't benefit anybody. Besides I don't have the desire to add unison to supersaw and fm anyways.


.travis.yml: use rustfmt from the stable toolchain only

The nightly one can vary wildly with regressions and turn PR's red
needing short-lived changes that in turn will fail when the
regressions are fixed. So use rustfmt as shipped with stable.

Codecov Report

Merging #57 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #57   +/-   ##
=======================================
  Coverage   95.55%   95.55%
=======================================
  Files          11       11
  Lines         922      922
=======================================
  Hits          881      881
  Misses         41       41

Impacted Files
Coverage Δ

src/lib.rs
90.9% <0%> (-9.1%)
:arrow_down:

src/api_call.rs
88.23% <0%> (+2.94%)
:arrow_up:

Continue to review full report at Codecov.

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

bors r=@PhilipGough


Review all error messages for usability and convert to GO 1.13 errors

Go 1.13 added new Unwrap and errors.Is ans errors.As helpers based on the popularity of libraries like github.com/pkg/errors which we currently use.  We should switch to the new standard library way of doing things and remove our dependency on the errors package.  This is  also a good opportunity to review the error messages for usability and consistency.
Background reading on go 1.13 errors here: https://blog.golang.org/go1.13-errors

I don't think this is worth fixing right now.  It's uite a bit of work and pkg/errors is doing the job


How to Run Custom Python Library as a Facet Transformation?

Describe the bug
I packaged my module and now it resides in my python2.7 site-packages. Now, when I go to OpenRefine and try to transform a column into a new column using this python module, it doesn't do anything.
Code
import sys
sys.path.append('/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages')
from openrefinepylib.military_gov_id import classify
return classify(value, '/Users/rihun/secrets/daodl_access.json')

Current Results
The new column is created but without any values
Expected behavior
There should be values for this new column
Screenshots

Desktop (please complete the following information):

OS: MacOS
Browser Version: Chrome

OpenRefine (please complete the following information):

Version 3.3

For added context,
Here is my python module that I've packaged:
from google.auth.transport.requests import AuthorizedSession
from google.oauth2 import service_account
import json
def classify(entity_name, service_account_file):

    party_names = [entity_name]

    TARGET_AUDIENCE = <TARGET_AUDIENCE>
    URL = <API_URL>

    creds = service_account.IDTokenCredentials.from_service_account_file(
            service_account_file,
            target_audience=TARGET_AUDIENCE)

    authed_session = AuthorizedSession(creds)

    payload = {
            "entity_name": party_names
        }

    resp = authed_session.post(URL,
                               headers={'Content-Type': 'application/json'},
                               json=payload)

    return json.loads(resp.text)[0]['predicted_classification']

I then installed jython2.7.2 separately and used pip to install the custom module and its required dependencies.
When I try to import this module from jython2.7.2 site-packages in OpenRefine, I get the following error:
ImportError: cannot import name oauth2
This is an odd error because oauth2 and google-oauth2 are installed in jython2.7.2

@rileyhun Jython as our extension on its own path is what gets added to our classpath via Butterfly.  So instead of your Python sys path...use the Jython one.  Alternatively, you can download Jython independently, add it to your path, and then use pip or drop in your package into the locally installed jython\Lib\site-packages\ folder.
I wrote some of this up already here, if you haven't seen it yet:
https://github.com/OpenRefine/OpenRefine/wiki/Extending-Jython-with-pypi-modules

@rileyhun Specifically, you might be hitting this problem that I mentioned in the wiki guide?

NOTE : if you already have a Python version installed, pip install  will install the module in your first Python distribution, not in Jython. To work around the problem, use this command instead :
C:\Users\Thad>jython -m pip install address-formatter

@rileyhun Jython as our extension on its own path is what gets added to our classpath via Butterfly. So instead of your Python sys path...use the Jython one. Alternatively, you can download Jython independently, add it to your path, and then use pip or drop in your package into the locally installed jython\Lib\site-packages\ folder.
I wrote some of this up already here, if you haven't seen it yet:
https://github.com/OpenRefine/OpenRefine/wiki/Extending-Jython-with-pypi-modules

Thanks @thadguidry, I am also trying it with the jython site-packages I've installed and I'm getting this error still.
Code Example:
import sys
sys.path.append('/Users/rihun/jython2.7.0/Lib/site-packages')
from openrefinepylib.military_gov_id import classify
return classify(value, '/Users/rihun/secrets/daodl_access.json')

Just for experimentation purposes, I disregarded my custom module, and just tried to see if openrefine had access to my local jython site-packages. So I tried this block of code:
import sys
sys.path.append('/Users/rihun/jython2.7.0/Lib/site-packages')
import requests
r = requests.get('http://cbc.ca')
return r.text[0]

It returned that same error regarding oauth2
ImportError: No module named oauth2
For some reason jython is having trouble reading oauth2.

Can we try to explicitly tell Jython to append the path for oauth2 ?
And in the meantime...I'm firing up my environment to try to mimic this now...

Can we try to explicitly tell Jython to append the path for oauth2 ?
And in the meantime...I'm firing up my environment to try to mimic this now...

Could you kindly clarify what you mean? ouath2 is already in the jython2.7.0 site-packages and I've appended the path to this.

ok, understood now.  trying to reproduce...

Jython is running on the JVM, it's all pretty fast for general use cases.
You would have to probably just log some statements you need out to a file, something kinda like this:
import logging
import logging.handlers
import os

handler = logging.handlers.WatchedFileHandler(
    os.environ.get("LOGFILE", "/var/log/yourapp.log"))
formatter = logging.Formatter(logging.BASIC_FORMAT)
handler.setFormatter(formatter)
root = logging.getLogger()
root.setLevel(os.environ.get("LOGLEVEL", "INFO"))
root.addHandler(handler)

try:
    exit(main())
except Exception:
    logging.exception("Exception in main()")
    exit(1)

You might also look into outputting INFO or DEBUG logs for the various libraries you are utilizing if they have options.

Anyways, glad you solved your issue.  I'll close this now.  For Python help, look to the Python communities on Stackoverflow or the #Python channel on Freenode IRC.

Well this is working for the the experiment I tried. Still not working with the custom python library I developed.


Apollo example error

When I first run this example I can get it to work but if refresh the page I get the following error:
TypeError: Cannot assign to read only property '1' of [object Array]
at Array.sort (native)
at PostList (C:\next.js\examples\with-apollo\components\PostList.js:20:27)
at walkTree (C:\next.js\examples\with-apollo\node_modules\react-apollo\src\server.ts:76:15)
at walkTree (C:\next.js\examples\with-apollo\node_modules\react-apollo\src\server.ts:80:7)
at getQueriesFromTree (C:\next.js\examples\with-apollo\node_modules\react-apollo\src\server.ts:102:3)
at getDataFromTree (C:\next.js\examples\with-apollo\node_modules\react-apollo\src\server.ts:123:17)
at C:\next.js\examples\with-apollo\node_modules\react-apollo\src\server.ts:131:28
at process._tickCallback (node.js:385:9)
It also works if I change the file and re-save it. If I refresh after that it stops working again.
I have set my graph.cool end point in initClient.js. Is there something I am not doing correctly?

@abelovic Does it work with the graph.cool endpoint provided in the example? Seems like could be an issue with your graph.cool endpoint. GraphQL API's are self-documenting so you can see if the API used in the example matches up with the one you created using the graphiql interface.

This does not work for me with the end point in the example. This is all I did:

clone next.js
navigate to with-apollo sample
run npm install
npm run dev
open on localhost:3000

This pulls up for me with an error and I experience the symptoms described in my initial post i.e. works once when saving :(
In the graphiql interface:
query allPosts($first: Int!, $skip: Int!) {
allPosts(orderBy: createdAt_DESC, first: $first, skip: $skip) {
id
title
votes
url
createdAt
}
_allPostsMeta {
count
}
}
variables:
{
"first": 10,
"skip": 0
}
And it returns data so I don't think its the endpoint. I'm on windows which would be the only other variable that may be different but don't see why that would cause an issue.
Can you try cloning this on your machine and running it? Maybe there is something different from what you deployed vs what's in github? Your demo link runs perfect.

@abelovic Good spot. The error was due to the assignment of a read-only property in the array which was happening when sorting the array. Simply remove sort() fixed the issue. I just submitted a pull request. Not sure why this error is only getting thrown now.

#900


{Security State, Device Life Cycle State[1:0]} documentation vs RTL mismatch

From the following document, https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#caliptra-security-states we see the Caliptra security state encoding as follows:

{Security State, Device Life Cycle State[1:0]}
State

000b
DebugUnlocked and Unprovisioned

100b
DebugLocked and Manufacturing

101b
DebugLocked and Production

001b
DebugUnlocked and Production

However, looking at the RTL it appears to be below encoding.

{Security State, Device Life Cycle State[1:0]}
State

000b
DebugUnlocked and Unprovisioned

101b
DebugLocked and Manufacturing

111b
DebugLocked and Production

011b
DebugUnlocked and Production

Mahmud filed a similar one on spec long time - not sure what happened with that. I will check with him too

Confirmed with Anthony that ROM matches the encoding in RTL. So it sounds like we just need to update the spec.

Here is the PR to fix it: https://github.com/chipsalliance/Caliptra/pull/135

The concern I had originally was about the spec encoding of the lower two bits, Device Lifecycle State[1:0] -- does 00b indicate Unprovisioned or Manufacturing?
The RTL does not have this contradiction. If the spec is updated to match the ROM and RTL, no further action is needed:

00b => Unprovisioned
01b => Manufacturing
11b => Production

fixed in main spec https://github.com/chipsalliance/Caliptra/issues/19


feat: compute the distributive Haar character of ℝ, ℂ, ℤ_[p] and ℚ_[p]

Co-authored-by: Javier López-Contreras<EMAIL_ADDRESS>

[x] depends on: #263

Here are two ideas which are (to me) distinct. [...]

Yes, Javier and I ended up understanding what you meant by "This is not what the literature calls modular characters". Will update this PR later today

Thanks so much for your work on this!


State cache

WIP!!!!
What was wrong?
How was it fixed?
To-Do

[ ] Clean up commit history

[ ] Add entry to the release notes PR

Cute Animal Picture

Closing due to staleness, can revisit if needed :)


Fixes integration tests

Integration tests were broken after #10326 since a new action was added to the right click menu.
This PR adds the new menu option to the expected elements array.

All good its why we have the tests :D


V2 Install not working

Probably a really simple solution, but I'm getting the following errors when running pip install TotalSegmentator:
ERROR: Could not find a version that satisfies the requirement nnunetv2==2.2 (from TotalSegmentator) (from versions: 2.0) ERROR: No matching distribution found for nnunetv2==2.2 (from TotalSegmentator)
Any easy fix?

Strange. I have never experienced this error. This should normally work.

Upgraded to Python 3.9 from 3.8 and it worked fine.

Good point. I updated the readme to contain this information.


Prevent background scrolling on iOS devices

Is there currently a way to prevent the page that _calls _(and is visible underneath) the modal from scrolling?  For instance, on iOS devices, when you open a remodal, you can still scroll the underlying page behind it by swiping your finger.   I didn't see anything in the docs.  Thank you so much for your assistance.

No, there isn't a good solution.


i got a error when i build the cheat

so i keep getting a error when i build nad i allready have a bunch of extensions or whatever there called
error:
fatal error C1083: Cannot open include file: 'd3dx9.h': No such file or directory

install dx9 sdk

thanks dad


Wrong Default for Gain

According to the datasheet the default should be 9 or 256x:

I could see this being an issue for someone coming from Arduino or looking at the datasheet graphs.

@NeoStormer do you happen to have a link for data sheet or a reference of what page or section this quote was pulled from?
Are you interested in submitting a PR with this change?

I've had a closer look into the datasheet and I'm not sure the sections referencing that default value are for features that this library implements. The references I could find are:

Which note the default values for AGC_FD_GAIN_MAX and AGC_AGAIN_MAX which are in the register 0xCF
The gain value that is implemented in this library currently is rooted here: https://github.com/adafruit/Adafruit_CircuitPython_AS7341/blob/0a7b934ce8a0c0bcdda18abc5d376aa37ae9301b/adafruit_as7341.py#L344 and it's set to us the register _AS7341_CFG1 or 0xAA which is documented in a different section of the datasheet.

In that section it doesn't mention anything about a default value.
As far as I can tell nothing in this library interacts with register 0xCF at all currently.  So my understanding is that the defaults mentioned for values in that register don't apply to this driver as it's written today.
I'm going to close this for now. Feel free to re-open if you believe there is still some issue and can provide more details.


Broken 1.30.6 AWS image - Not being able to pull sleep image

What happened:
Spawned a new kubernetes node via karpenter.
Node did not come up.
Saw in the error logs:
Events:
  Type     Reason                  Age               From               Message
  ----     ------                  ----              ----               -------
  Normal   Scheduled               27s               default-scheduler  Successfully assigned kube-system/aws-node-scbkb to ip-192-168-167-69.eu-central-1.compute.internal
  Warning  FailedCreatePodSandBox  1s (x3 over 26s)  kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to get sandbox image "localhost/kubernetes/pause": failed to pull image "localhost/kubernetes/pause": failed to pull and unpack image "localhost/kubernetes/pause:latest": failed to resolve reference "localhost/kubernetes/pause:latest": failed to do request: Head "https://localhost/v2/kubernetes/pause/manifests/latest": dial tcp <IP_ADDRESS>:443: connect: connection refused

What you expected to happen:
Node comes up.
How to reproduce it (as minimally and precisely as possible):
How I could fix it:

ssh to the node.
Fix the sleep container (which has a wrong source)

# from
[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "localhost/kubernetes/pause"
# to
[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "k8s.gcr.io/pause:3.9"

service containerd restart
ctr images pull k8s.gcr.io/pause:3.9

Node comes up again.
Seems odd. Not 100% sure yet if it is karpenter fault / AWS ami fault.
Environment:

AWS Region: eu-central-1
Instance Type(s):  c6id.24xlarge
Cluster Kubernetes version: 1.30
Node Kubernetes version: 1.30.6
AMI Version: ami-0d6c630f239d638a6 / amazon-eks-node-al2023-x86_64-standard-1.30-v20241115
Karpenter version: 1.0.7

Solved it ourselves.
We had a custom nvme mount script, which was working till now.
But it remounted /var/lib/containerd creating these problems.

@thomaspeitz makes sense, please let us know if you run into any more issues with the pause image. We're trying to remove the runtime dependency on ECR, it's a frequent source of flakiness/footguns (more info in #2000).

@cartermckinnon - No, works perfectly on all clusters. Very happy about it. Thanks for this improvement. Especially those seconds to have faster nodes up, are totally worth to refactor some nodes. Besides the win, when ecr is down.
It only effected our nvme nodes.
Have some blog post about nvme + gist. Updated as well to ensure it rsyncs the content before remounting it.
https://gist.github.com/thomaspeitz/eaef87c714418eb1fe1a732655d4637b

added a note on your gist - you don't need to do all of that in user data. the EKS AL2 and AL2023 both have provisions to mount the instance store volumes - see the Al2023 version in the comment https://gist.github.com/thomaspeitz/eaef87c714418eb1fe1a732655d4637b?permalink_comment_id=5293458#gistcomment-5293458


Current condition icon doesn't load

Checklist:

[ x] I updated to the latest version available
[ x] I cleared the cache of my browser

Release with the issue:
0.03
Last working release (if known):
Unknown
Browser and Operating System:
Chrome/mobile app

Description of problem:
When weather entity set, icon displays as hazard/caution sign only.

card_config_version: 4
daily_forecast_days: 5
entity_apparent_temp: sensor.toronto_humidex
entity_current_conditions: sensor.toronto_current_condition
entity_current_text: sensor.toronto_current_condition
entity_daily_summary: sensor.toronto_summary
entity_forecast_high_temp_1: weather.toronto
entity_forecast_icon_1: weather.toronto
entity_forecast_low_temp_1: weather.toronto
entity_forecast_max: sensor.toronto_high_temperature
entity_forecast_min: sensor.toronto_low_temperature
entity_humidity: sensor.toronto_humidity
entity_pop: sensor.toronto_chance_of_precipitation
entity_pop_1: weather.toronto
entity_possible_today: sensor.toronto_chance_of_precipitation
entity_pressure: sensor.toronto_barometric_pressure
entity_sun: sun.sun
entity_temperature: weather.toronto
entity_uv_alert_summary: sensor.toronto_uv_index
entity_wind_bearing: sensor.toronto_wind_bearing
entity_wind_gust: sensor.toronto_wind_gust
entity_wind_speed: sensor.toronto_wind_speed
extended_use_attr: false
option_icon_set: new
option_pressure_decimals: 1
option_static_icons: false
option_today_decimals: true
option_tooltips: true
section_order:
  - title
  - overview
  - extended
  - slots
  - daily_forecast
show_decimals: true
show_section_title: false
show_separator: true
slot_l1: forecast_max
slot_l2: forecast_min
slot_l3: wind
slot_l4: pressure
slot_l5: sun_next
slot_l6: remove
slot_l7: remove
slot_l8: remove
slot_r1: pop
slot_r2: humidity
slot_r3: uv_summary
slot_r4: empty
slot_r5: sun_following
slot_r6: remove
slot_r7: remove
slot_r8: remove
type: custom:platinum-weather-card

Javascript errors shown in the web inspector (if applicable):

Additional information:

I am currently reworking and enhancing the icons being used. But this is not expected. Can I ask what the state of weather.toronto is.

Full output is attached as a screenshot.  Happy to test as needed.
On Sun., Jul. 24, 2022, 8:24 a.m. Simon, @.***> wrote:

I am currently reworking and enhancing the icons being used. But this is
not expected. Can I ask what the state of weather.toronto is.
—
Reply to this email directly, view it on GitHub
https://github.com/Makin-Things/platinum-weather-card/issues/39#issuecomment-1193307795,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL4QL4JYXLYLIFW6XLAOQSLVVUYXHANCNFSM54PN2TKQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

Please show the state as shown in developer tools

partlycloudy. The screenshot is the entire developer tool data/attributes
of weather.toronto
On Sun., Jul. 24, 2022, 8:40 a.m. Simon, @.***> wrote:

Please show the state as shown in developer tools
—
Reply to this email directly, view it on GitHub
https://github.com/Makin-Things/platinum-weather-card/issues/39#issuecomment-1193310533,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL4QL4MSFAYAJWWQGLYFK3DVVU2TPANCNFSM54PN2TKQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

Ok. That looks like a proper bug after a quick look. It appears that partlycloudy isn't being handled properly. It's close to midnight here now so I will do a fix tomorrow.

Ok, I was really tired when looking at this last night. It's not a bug, you are using the wrong entity.

Change this to use weather.toronto

That worked.
May want to include in the docs that if there is a current conditions
entity to use the weather one.
The rest of this looks good. Really slick.
On Sun., Jul. 24, 2022, 7:18 p.m. Simon, @.***> wrote:

Ok, I was really tired when looking at this last night. It's not a bug,
you are using the wrong entity.
[image: image]
https://user-images.githubusercontent.com/91187456/180669826-12135fd4-ebaf-42e0-94fc-70e2eb583a77.png
Change this to use weather.toronto
—
Reply to this email directly, view it on GitHub
https://github.com/Makin-Things/platinum-weather-card/issues/39#issuecomment-1193414216,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL4QL4M44C77OJSNAKRXIKDVVXFNNANCNFSM54PN2TKQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

I am currently reworking the whole icon part of the card to add flexibility. I haven't done the documentation for the overview part as I would probably have to completely redo it.

Makes sense. It's looking really good and wasn't too complicated to figure
out.
Thanks for working on this, excited to use it.
On Sun., Jul. 24, 2022, 7:26 p.m. Simon, @.***> wrote:

I am currently reworking the whole icon part of the card to add
flexibility. I haven't done the documentation for the overview part as I
would probably have to completely redo it.
—
Reply to this email directly, view it on GitHub
https://github.com/Makin-Things/platinum-weather-card/issues/39#issuecomment-1193416100,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL4QL4NALOOWF22656RNO2LVVXGIPANCNFSM54PN2TKQ
.
You are receiving this because you authored the thread.Message ID:
@.***>


Opencv with Qt cmd remains after actual opencv window is closed when it should be closed also

OpenCV version: 2.4 / 3
Host OS:  Windows 7/10

have opencv various versions with Qt 4.x or 5.x    build with visual sutdio 2010
when i run my exe, with simple opencv loading an image , waitkey and release , Qt seems to keep open the cmd window if i close the opecv window. ( it only closes the cmd window if i press button to realease and destroy window from code).  this cmd also has output ''init done''.
without QT build, the cmd closes automatically when i close the opencv window, as expected.
moreover the exe, when i have the QT builded opencv, seems to have a memory leak and doesnt let me delete it.

Please provide minimal reproducing example and your OpenCV configuration (returned by cv::getBuildInformation).


Pr_awkward_in_20

Fixes #316

This is a stop-gap fix until 3.0 is released, so I'm not too worried about the drop in code coverage.


Update: Meltytech.Shotcut version 21.05.18

Removing old versions to reduce clutter
Microsoft Reviewers: Open in CodeFlow

/azp run


Fixes ICE 469

What was wrong?

The following does currently lead to an ICE (see #469 found by the fuzzer)

contract Foo:
  pub def bar:
    (x,):u256[20]=[1,2,3,4,5,6,7,8,9,0,2,1,3,4,5,6,7,8,9,0]

The reason here is that the type u256[20] is wrong since we are destructuring into a tuple

The following also leads to to an ICE

contract Foo:
  pub def bar():
    (x, y):(u256,)=(1,)

The reason here is that the number of items between (x, y) (2 items) and the declared type (u256,) (1 item) doesn't match.
How was it fixed?
Just added nice user messages. The error was already caught but we didn't have proper user errors yet which caused the ICE.

Codecov Report

Merging #484 (36e5daf) into master (1a561b1) will decrease coverage by 0.03%.
The diff coverage is 60.60%.

:exclamation: Current head 36e5daf differs from pull request most recent head fb1669f. Consider uploading reports for the commit fb1669f to get more accurate results

@@            Coverage Diff             @@
##           master     #484      +/-   ##
==========================================
- Coverage   87.68%   87.64%   -0.04%
==========================================
  Files          77       78       +1
  Lines        5237     5246       +9
==========================================
+ Hits         4592     4598       +6
- Misses        645      648       +3

Impacted Files
Coverage Δ

crates/analyzer/src/errors.rs
25.00% <25.00%> (ø)

crates/analyzer/src/traversal/expressions.rs
91.19% <36.36%> (ø)

crates/analyzer/src/traversal/functions.rs
91.12% <50.00%> (ø)

crates/analyzer/src/traversal/declarations.rs
91.66% <71.42%> (+2.19%)
:arrow_up:

crates/analyzer/src/traversal/assignments.rs
69.23% <100.00%> (ø)

crates/analyzer/src/traversal/types.rs
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Stream with a closed writer?

Hey there, I got a object disposed exception for following code:
        CacheItem ITranscoder.Serialize(object value)
        {
            const string serializeTag = "JsonTranscoder.Serialize";
            using (var stream = Manager.GetStream(serializeTag))
            {
                using (var writer = new StreamWriter(stream, Enc8))
                {
                    JsonSerializer.Serialize(writer, value, typeof(object));
                }

                stream.TryGetBuffer(out var byteSegment);
                return new CacheItem { Data = byteSegment };
            }
        }

But when using the MemoryStream version, there is no error:
        CacheItem ITranscoder.Serialize(object value)
        {
            using (var stream = new MemoryStream())
            {
                using (var writer = new StreamWriter(stream, Enc8))
                {
                    JsonSerializer.Serialize(writer, value, typeof(object));
                }

                stream.TryGetBuffer(out var byteSegment);
                return new CacheItem { Data = byteSegment };
            }
        }

Looking the StreamWriter source, it looks like when dispose the StreamWriter the stream inside StreamWriter(stream, Enc8)) got called for dispose as well and caused double dispose.
Is there a recommendation regarding how to handle this scenario?

Use the overload of StreamWriter.ctor that has bool leaveOpen. RecyclableMemoryStream is a lot more picky about using it after disposal, out of necessity because it's pooled.

Use the overload of StreamWriter.ctor that has bool leaveOpen. RecyclableMemoryStream is a lot more picky about using it after disposal, out of necessity because it's pooled.

Thank you @benmwatson , this is to confirm the overload constructor fixes the issue. Appreciated!

Thank you @benmwatson , this is to confirm the overload constructor fixes the issue. Appreciated!


Reactive form patch value makes the form dirty

Hi,
Ngx-wig implementation with reactive form controls.
Patching a value using patchValue makes the form dirty, which shouldn't be the case.
Following is the stackblitz implementation:
https://stackblitz.com/edit/ngx-wig-sample7-u7huhp?file=src%2Fapp.ts
Thanks,
Manish

Hi @mkdudeja,
thank you for detailed feedback with an example!
I've made PR with a fix
https://github.com/stevermeister/ngx-wig/pull/109/files

please use version<EMAIL_ADDRESS>


Add FO4 specific log path

When used for Fallout 4 plugins, the logger dumps files in the root directory.
Now it ✨ doesn't ✨.

😍


Define type VarlenEntry. Rewrite test to test more things.

Apparently I screwed up and #28 has these changes. Closing this PR.


[tuya iot] error while get mqtt config

Describe the bug
Home Assistant latest integration, getting:
2021-08-06 23:56:56 ERROR (Thread-5) [tuya iot] error while get mqtt config
2021-08-06 23:56:56 ERROR (Thread-5) [root] Uncaught thread exception
Traceback (most recent call last):
File "/usr/local/lib/python3.9/threading.py", line 973, in _bootstrap_inner
self.run()
File "/usr/local/lib/python3.9/site-packages/tuya_iot/openmq.py", line 173, in run
time.sleep(self.mq_config.expireTime - 60)
AttributeError: 'TuyaOpenMQ' object has no attribute 'mq_config'
Expected behavior
The device added after adding the integration, but status updates not working.
Home Assistant Version
2021.8.2

I had the same issue, I resolved it by enabling the "Device status notification" API in the Tuya IoT platform. If you haven't already I'd give that a go.

All my devices were working fine, now the status updates seem to have stopped, if I reload the integration or reboot HA then they work for a minute or so, then stop.
I already have the device status notification enabled in the IoT platform, have had it for weeks.

Logger: root
Source: helpers/entity.py:604
First occurred: August 17, 2021, 7:12:18 PM (7 occurrences)
Last logged: 7:10:54 AM
Uncaught thread exception
Traceback (most recent call last):
File "/usr/local/lib/python3.9/threading.py", line 973, in _bootstrap_inner
self.run()
File "/usr/local/lib/python3.9/threading.py", line 910, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 3452, in _thread_main
self.loop_forever(retry_first_connection=True)
File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 1779, in loop_forever
rc = self.loop(timeout, max_packets)
File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 1181, in loop
rc = self.loop_read(max_packets)
File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 1572, in loop_read
rc = self._packet_read()
File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 2310, in _packet_read
rc = self._packet_handle()
File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 2936, in _packet_handle
return self._handle_publish()
File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 3216, in _handle_publish
self._handle_on_message(message)
File "/usr/local/lib/python3.9/site-packages/paho/mqtt/client.py", line 3444, in _handle_on_message
self.on_message(self, self._userdata, message)
File "/usr/local/lib/python3.9/site-packages/tuya_iot/openmq.py", line 157, in _on_message
listener(msgDict)
File "/usr/local/lib/python3.9/site-packages/tuya_iot/device.py", line 175, in on_message
self._on_device_report(data["devId"], data["status"])
File "/usr/local/lib/python3.9/site-packages/tuya_iot/device.py", line 196, in _on_device_report
self.__update_device(device)
File "/usr/local/lib/python3.9/site-packages/tuya_iot/device.py", line 183, in __update_device
listener.update_device(device)
File "/config/custom_components/tuya_v2/init.py", line 164, in update_device
ha_device.schedule_update_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 604, in schedule_update_ha_state
self.hass.add_job(self.async_update_ha_state(force_refresh))  # type: ignore
AttributeError: 'NoneType' object has no attribute 'add_job'

I think something wrong after the integration start. Can you provide the full log after reboot HA?

Same prob
2021-09-17 23:40:37,565] [tuya-openmq] error while get mqtt config
2021-09-17 23:40:37 ERROR (Thread-3) [tuya iot] error while get mqtt config
2021-09-17 23:40:37 ERROR (Thread-3) [root] Uncaught thread exception
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/threading.py", line 973, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.9/site-packages/tuya_iot/openmq.py", line 173, in run
    time.sleep(self.mq_config.expireTime - 60)
AttributeError: 'TuyaOpenMQ' object has no attribute 'mq_config'

Home Assistant 2021.9.6
Led strip lights are working fine, just this error accours...

Same prob

2021-09-17 23:40:37,565] [tuya-openmq] error while get mqtt config

2021-09-17 23:40:37 ERROR (Thread-3) [tuya iot] error while get mqtt config

2021-09-17 23:40:37 ERROR (Thread-3) [root] Uncaught thread exception

Traceback (most recent call last):

  File "/usr/local/lib/python3.9/threading.py", line 973, in _bootstrap_inner

    self.run()

  File "/usr/local/lib/python3.9/site-packages/tuya_iot/openmq.py", line 173, in run

    time.sleep(self.mq_config.expireTime - 60)

AttributeError: 'TuyaOpenMQ' object has no attribute 'mq_config'

Home Assistant 2021.9.6
Led strip lights are working fine, just this error accours...

Hi
This comment solved me the problem
https://github.com/tuya/tuya-home-assistant/issues/320#issuecomment-894926742

Same prob

2021-09-17 23:40:37,565] [tuya-openmq] error while get mqtt config

2021-09-17 23:40:37 ERROR (Thread-3) [tuya iot] error while get mqtt config

2021-09-17 23:40:37 ERROR (Thread-3) [root] Uncaught thread exception

Traceback (most recent call last):

  File "/usr/local/lib/python3.9/threading.py", line 973, in _bootstrap_inner

    self.run()

  File "/usr/local/lib/python3.9/site-packages/tuya_iot/openmq.py", line 173, in run

    time.sleep(self.mq_config.expireTime - 60)

AttributeError: 'TuyaOpenMQ' object has no attribute 'mq_config'

Home Assistant 2021.9.6
Led strip lights are working fine, just this error accours...

Hi
This comment solved me the problem
#320 (comment)

I have enabled this already :)


cilium/cmd: Replace exit code -1 with exit code 1

In two cases, cilium could exit with code -1, which gets converted to
255. Instead, always exit with code 1 in the event of failure. Also,
remove an unnecessary os.Exit(0).

test-me-please

LGTM once the instances found by @sayboras get fixed as well for consistency's sake

This is done in #13798.

let's wait on the next release (see https://github.com/cilium/cilium/pull/13798#issuecomment-718557055) before merging this.


Scripts don't work under opensuse tumbleweed

It says can't install linux-firmware, maybe the real name is kernel-firmware-all.

Seems like I either missed this or opensuse changed something recently, either way it should work now.

Seems like I either missed this or opensuse changed something recently, either way it should work now.

I had posted in the old eupnea issues about this, the -f option not existing. IDK what happened to that repo but I really appreciate this one, thank you.


[FSDE-1349] Added DevOpsGCR Enhancements and fixes

@davisein  this PR will update the JSL release so CHI will have the requested changes in the attachment normalization besides some fixes and enhancements

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-121/1/. :white_check_mark:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-121/2/. :white_check_mark:

You can check this PRs instance in https://da6c1f7647011e674f53b9924ada7e7e6f4e7703-chi-pr.enterprise.ctl.io

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-121/3/. :white_check_mark:

You can check this PRs instance in https://ca3c4139c0171d99078434179ab04ba7352d7a68-chi-pr.enterprise.ctl.io


Rename about-protected-branches.md to about-protected-branches.tmd

content/codespaces/managing-codespaces-for-your-organization/enabling-codespaces-for-your-organization.md title: About protected branches
intro: 'You can protect important branches by setting branch protection rules, which define whether collaborators can delete or force push to the branch and set requirements for any pushes to the branch, such as passing status checks or a linear commit history.'
product: '{% data reusables.gated-features.protected-branches %}'
redirect_from:

/articles/about-protected-branches
/enterprise/admin/developer-workflow/about-protected-branches-and-required-status-checks
/articles/about-branch-restrictions
/github/administering-a-repository/about-branch-restrictions
/articles/about-required-status-checks
/github/administering-a-repository/about-required-status-checks
/articles/types-of-required-status-checks
/github/administering-a-repository/types-of-required-status-checks
/articles/about-required-commit-signing
/github/administering-a-repository/about-required-commit-signing
/articles/about-required-reviews-for-pull-requests
/github/administering-a-repository/about-required-reviews-for-pull-requests
/github/administering-a-repository/about-protected-branches
/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches
versions:
fpt: ''
ghes: ''
ghae: ''
ghec: ''
topics:
Repositories

About branch protection rules
You can enforce certain workflows or requirements before a collaborator can push changes to a branch in your repository, including merging a pull request into the branch, by creating a branch protection rule.
By default, each branch protection rule disables force pushes to the matching branches and prevents the matching branches from being deleted. You can optionally disable these restrictions and enable additional branch protection settings.
By default, the restrictions of a branch protection rule don't apply to people with admin permissions to the repository. You can optionally choose to include administrators, too.
{% data reusables.repositories.branch-rules-example %} For more information about branch name patterns, see "Managing a branch protection rule."
{% data reusables.pull_requests.you-can-auto-merge %}
About branch protection settings
For each branch protection rule, you can choose to enable or disable the following settings.

Require pull request reviews before merging
Require status checks before merging
{% ifversion fpt or ghes > 3.1 or ghae or ghec %}
Require conversation resolution before merging{% endif %}
Require signed commits
Require linear history
{% ifversion fpt or ghec %}
Require merge queue
{% endif %}
Include administrators
Restrict who can push to matching branches
Allow force pushes
Allow deletions

For more information on how to set up branch protection, see "Managing a branch protection rule."
Require pull request reviews before merging
{% data reusables.pull_requests.required-reviews-for-prs-summary %}
If you enable required reviews, collaborators can only push changes to a protected branch via a pull request that is approved by the required number of reviewers with write permissions.
If a person with admin permissions chooses the Request changes option in a review, then that person must approve the pull request before the pull request can be merged. If a reviewer who requests changes on a pull request isn't available, anyone with write permissions for the repository can dismiss the blocking review.
{% data reusables.repositories.review-policy-overlapping-commits %}
If a collaborator attempts to merge a pull request with pending or rejected reviews into the protected branch, the collaborator will receive an error message.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.

Optionally, you can choose to dismiss stale pull request approvals when commits are pushed. If anyone pushes a commit that modifies code to an approved pull request, the approval will be dismissed, and the pull request cannot be merged. This doesn't apply if the collaborator pushes commits that don't modify code, like merging the base branch into the pull request's branch. For information about the base branch, see "About pull requests."
Optionally, you can restrict the ability to dismiss pull request reviews to specific people or teams. For more information, see "Dismissing a pull request review."
Optionally, you can choose to require reviews from code owners. If you do, any pull request that affects code with a code owner must be approved by that code owner before the pull request can be merged into the protected branch.
Require status checks before merging
Required status checks ensure that all required CI tests are passing before collaborators can make changes to a protected branch. Required status checks can be checks or statuses. For more information, see "About status checks."
Before you can enable required status checks, you must configure the repository to use the status API. For more information, see "Repositories" in the REST documentation.
After enabling required status checks, all required status checks must pass before collaborators can merge changes into the protected branch. After all required status checks pass, any commits must either be pushed to another branch and then merged or pushed directly to the protected branch.
Any person or integration with write permissions to a repository can set the state of any status check in the repository, but in some cases you may only want to accept a status check from a specific {% data variables.product.prodname_github_app %}. When you add a required status check, you can select an app that has recently set this check as the expected source of status updates. If the status is set by any other person or integration, merging won't be allowed. If you select "any source", you can still manually verify the author of each status, listed in the merge box.
You can set up required status checks to either be "loose" or "strict." The type of required status check you choose determines whether your branch is required to be up to date with the base branch before merging.

Type of required status check
Setting
Merge requirements
Considerations

Strict
The Require branches to be up to date before merging checkbox is checked.
The branch must be up to date with the base branch before merging.
This is the default behavior for required status checks. More builds may be required, as you'll need to bring the head branch up to date after other collaborators merge pull requests to the protected base branch.

Loose
The Require branches to be up to date before merging checkbox is not checked.
The branch does not have to be up to date with the base branch before merging.
You'll have fewer required builds, as you won't need to bring the head branch up to date after other collaborators merge pull requests. Status checks may fail after you merge your branch if there are incompatible changes with the base branch.

Disabled
The Require status checks to pass before merging checkbox is not checked.
The branch has no merge restrictions.
If required status checks aren't enabled, collaborators can merge the branch at any time, regardless of whether it is up to date with the base branch. This increases the possibility of incompatible changes.

For troubleshooting information, see "Troubleshooting required status checks."
{% ifversion fpt or ghes > 3.1 or ghae or ghec %}
Require conversation resolution before merging
Requires all comments on the pull request to be resolved before it can be merged to a protected branch. This ensures that all comments are addressed or acknowledged before merge.
{% endif %}
Require signed commits
When you enable required commit signing on a branch, contributors {% ifversion fpt or ghec %}and bots{% endif %} can only push commits that have been signed and verified to the branch. For more information, see "About commit signature verification."
{% note %}
{% ifversion fpt or ghec %}
Notes:

If you have enabled vigilant mode, which indicates that your commits will always be signed, any commits that {% data variables.product.prodname_dotcom %} identifies as "Partially verified" are permitted on branches that require signed commits. For more information about vigilant mode, see "Displaying verification statuses for all of your commits."
If a collaborator pushes an unsigned commit to a branch that requires commit signatures, the collaborator will need to rebase the commit to include a verified signature, then force push the rewritten commit to the branch.

{% else %}
Note: If a collaborator pushes an unsigned commit to a branch that requires commit signatures, the collaborator will need to rebase the commit to include a verified signature, then force push the rewritten commit to the branch.
{% endif %}
{% endnote %}
You can always push local commits to the branch if the commits are signed and verified. {% ifversion fpt or ghec %}You can also merge signed and verified commits into the branch using a pull request on {% data variables.product.product_name %}. However, you cannot squash and merge a pull request into the branch on {% data variables.product.product_name %} unless you are the author of the pull request.{% else %} However, you cannot merge pull requests into the branch on {% data variables.product.product_name %}.{% endif %} You can {% ifversion fpt or ghec %}squash and {% endif %}merge pull requests locally. For more information, see "Checking out pull requests locally."
{% ifversion fpt or ghec %} For more information about merge methods, see "About merge methods on {% data variables.product.prodname_dotcom %}."{% endif %}
Require linear history
Enforcing a linear commit history prevents collaborators from pushing merge commits to the branch. This means that any pull requests merged into the protected branch must use a squash merge or a rebase merge. A strictly linear commit history can help teams reverse changes more easily. For more information about merge methods, see "About pull request merges."
 For more information, see "Configuring pull request merges."
{% ifversion fpt or ghec %}
Require merge queue
{% data reusables.pull_requests.merge-queue-beta %}
{% data reusables.pull_requests.merge-queue-overview %}
{% data reusables.pull_requests.merge-queue-merging-method %}
{% data reusables.pull_requests.merge-queue-references %}
{% endif %}
Include administrators
By default, protected branch rules do not apply to people with admin permissions to a repository. You can enable this setting to include administrators in your protected branch rules.
Restrict who can push to matching branches
{% ifversion fpt or ghec %}
You can enable branch restrictions if your repository is owned by an organization using {% data variables.product.prodname_team %} or {% data variables.product.prodname_ghe_cloud %}.
{% endif %}
When you enable branch restrictions, only users, teams, or apps that have been given permission can push to the protected branch. You can view and edit the users, teams, or apps with push access to a protected branch in the protected branch's settings.
You can only give push access to a protected branch to users, teams, or installed {% data variables.product.prodname_github_apps %} with write access to a repository. People and apps with admin permissions to a repository are always able to push to a protected branch.
Allow force pushes
By default, {% data variables.product.product_name %} blocks force pushes on all protected branches. When you enable force pushes to a protected branch, anyone with at least write permissions to the repository can force push to the branch, including those with admin permissions. If someone force pushes to a branch, the force push may overwrite commits that other collaborators based their work on. People may have merge conflicts or corrupted pull requests.
Enabling force pushes will not override any other branch protection rules. For example, if a branch requires a linear commit history, you cannot force push merge commits to that branch.
{% ifversion ghes or ghae %}You cannot enable force pushes for a protected branch if a site administrator has blocked force pushes to all branches in your repository. For more information, see "[Blocking force pushes to repositories owned by a user account or organization](/enterprise/{{ currentVersion }}/admin/developer-workflow/blocking-force-pushes-to-repositories-owned-by-a-user-account-or-organization)."
If a site administrator has blocked force pushes to the default branch only, you can still enable force pushes for any other protected branch.{% endif %}
Allow deletions
By default, you cannot delete a protected branch. When you enable deletion of a protected branch, anyone with at least write permissions to the repository can delete the branch.

Why:
Closes [issue link]

What's being changed:

Check off the following:

[x] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[x] This pull request impacts the contribution experience

[x] I have added the 'writer impact' label
[x] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

title: About protected branches
intro: 'You can protect important branches by setting branch protection rules, which define whether collaborators can delete or force push to the branch and set requirements for any pushes to the branch, such as passing status checks or a linear commit history.'
product: '{% data reusables.gated-features.protected-branches %}'
redirect_from:

/articles/about-protected-branches
/enterprise/admin/developer-workflow/about-protected-branches-and-required-status-checks
/articles/about-branch-restrictions
/github/administering-a-repository/about-branch-restrictions
/articles/about-required-status-checks
/github/administering-a-repository/about-required-status-checks
/articles/types-of-required-status-checks
/github/administering-a-repository/types-of-required-status-checks
/articles/about-required-commit-signing
/github/administering-a-repository/about-required-commit-signing
/articles/about-required-reviews-for-pull-requests
/github/administering-a-repository/about-required-reviews-for-pull-requests
/github/administering-a-repository/about-protected-branches
/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches
versions:
fpt: ''
ghes: ''
ghae: ''
ghec: ''
topics:
Repositories

About branch protection rules
You can enforce certain workflows or requirements before a collaborator can push changes to a branch in your repository, including merging a pull request into the branch, by creating a branch protection rule.
By default, each branch protection rule disables force pushes to the matching branches and prevents the matching branches from being deleted. You can optionally disable these restrictions and enable additional branch protection settings.
By default, the restrictions of a branch protection rule don't apply to people with admin permissions to the repository. You can optionally choose to include administrators, too.
{% data reusables.repositories.branch-rules-example %} For more information about branch name patterns, see "Managing a branch protection rule."
{% data reusables.pull_requests.you-can-auto-merge %}
About branch protection settings
For each branch protection rule, you can choose to enable or disable the following settings.

Require pull request reviews before merging
Require status checks before merging
{% ifversion fpt or ghes > 3.1 or ghae or ghec %}
Require conversation resolution before merging{% endif %}
Require signed commits
Require linear history
{% ifversion fpt or ghec %}
Require merge queue
{% endif %}
Include administrators
Restrict who can push to matching branches
Allow force pushes
Allow deletions

For more information on how to set up branch protection, see "Managing a branch protection rule."
Require pull request reviews before merging
{% data reusables.pull_requests.required-reviews-for-prs-summary %}
If you enable required reviews, collaborators can only push changes to a protected branch via a pull request that is approved by the required number of reviewers with write permissions.
If a person with admin permissions chooses the Request changes option in a review, then that person must approve the pull request before the pull request can be merged. If a reviewer who requests changes on a pull request isn't available, anyone with write permissions for the repository can dismiss the blocking review.
{% data reusables.repositories.review-policy-overlapping-commits %}
If a collaborator attempts to merge a pull request with pending or rejected reviews into the protected branch, the collaborator will receive an error message.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.

Optionally, you can choose to dismiss stale pull request approvals when commits are pushed. If anyone pushes a commit that modifies code to an approved pull request, the approval will be dismissed, and the pull request cannot be merged. This doesn't apply if the collaborator pushes commits that don't modify code, like merging the base branch into the pull request's branch. For information about the base branch, see "About pull requests."
Optionally, you can restrict the ability to dismiss pull request reviews to specific people or teams. For more information, see "Dismissing a pull request review."
Optionally, you can choose to require reviews from code owners. If you do, any pull request that affects code with a code owner must be approved by that code owner before the pull request can be merged into the protected branch.
Require status checks before merging
Required status checks ensure that all required CI tests are passing before collaborators can make changes to a protected branch. Required status checks can be checks or statuses. For more information, see "About status checks."
Before you can enable required status checks, you must configure the repository to use the status API. For more information, see "Repositories" in the REST documentation.
After enabling required status checks, all required status checks must pass before collaborators can merge changes into the protected branch. After all required status checks pass, any commits must either be pushed to another branch and then merged or pushed directly to the protected branch.
Any person or integration with write permissions to a repository can set the state of any status check in the repository, but in some cases you may only want to accept a status check from a specific {% data variables.product.prodname_github_app %}. When you add a required status check, you can select an app that has recently set this check as the expected source of status updates. If the status is set by any other person or integration, merging won't be allowed. If you select "any source", you can still manually verify the author of each status, listed in the merge box.
You can set up required status checks to either be "loose" or "strict." The type of required status check you choose determines whether your branch is required to be up to date with the base branch before merging.

Type of required status check
Setting
Merge requirements
Considerations

Strict
The Require branches to be up to date before merging checkbox is checked.
The branch must be up to date with the base branch before merging.
This is the default behavior for required status checks. More builds may be required, as you'll need to bring the head branch up to date after other collaborators merge pull requests to the protected base branch.

Loose
The Require branches to be up to date before merging checkbox is not checked.
The branch does not have to be up to date with the base branch before merging.
You'll have fewer required builds, as you won't need to bring the head branch up to date after other collaborators merge pull requests. Status checks may fail after you merge your branch if there are incompatible changes with the base branch.

Disabled
The Require status checks to pass before merging checkbox is not checked.
The branch has no merge restrictions.
If required status checks aren't enabled, collaborators can merge the branch at any time, regardless of whether it is up to date with the base branch. This increases the possibility of incompatible changes.

For troubleshooting information, see "Troubleshooting required status checks."
{% ifversion fpt or ghes > 3.1 or ghae or ghec %}
Require conversation resolution before merging
Requires all comments on the pull request to be resolved before it can be merged to a protected branch. This ensures that all comments are addressed or acknowledged before merge.
{% endif %}
Require signed commits
When you enable required commit signing on a branch, contributors {% ifversion fpt or ghec %}and bots{% endif %} can only push commits that have been signed and verified to the branch. For more information, see "About commit signature verification."
{% note %}
{% ifversion fpt or ghec %}
Notes:

If you have enabled vigilant mode, which indicates that your commits will always be signed, any commits that {% data variables.product.prodname_dotcom %} identifies as "Partially verified" are permitted on branches that require signed commits. For more information about vigilant mode, see "Displaying verification statuses for all of your commits."
If a collaborator pushes an unsigned commit to a branch that requires commit signatures, the collaborator will need to rebase the commit to include a verified signature, then force push the rewritten commit to the branch.

{% else %}
Note: If a collaborator pushes an unsigned commit to a branch that requires commit signatures, the collaborator will need to rebase the commit to include a verified signature, then force push the rewritten commit to the branch.
{% endif %}
{% endnote %}
You can always push local commits to the branch if the commits are signed and verified. {% ifversion fpt or ghec %}You can also merge signed and verified commits into the branch using a pull request on {% data variables.product.product_name %}. However, you cannot squash and merge a pull request into the branch on {% data variables.product.product_name %} unless you are the author of the pull request.{% else %} However, you cannot merge pull requests into the branch on {% data variables.product.product_name %}.{% endif %} You can {% ifversion fpt or ghec %}squash and {% endif %}merge pull requests locally. For more information, see "Checking out pull requests locally."
{% ifversion fpt or ghec %} For more information about merge methods, see "About merge methods on {% data variables.product.prodname_dotcom %}."{% endif %}
Require linear history
Enforcing a linear commit history prevents collaborators from pushing merge commits to the branch. This means that any pull requests merged into the protected branch must use a squash merge or a rebase merge. A strictly linear commit history can help teams reverse changes more easily. For more information about merge methods, see "About pull request merges."
 For more information, see "Configuring pull request merges."
{% ifversion fpt or ghec %}
Require merge queue
{% data reusables.pull_requests.merge-queue-beta %}
{% data reusables.pull_requests.merge-queue-overview %}
{% data reusables.pull_requests.merge-queue-merging-method %}
{% data reusables.pull_requests.merge-queue-references %}
{% endif %}
Include administrators
By default, protected branch rules do not apply to people with admin permissions to a repository. You can enable this setting to include administrators in your protected branch rules.
Restrict who can push to matching branches
{% ifversion fpt or ghec %}
You can enable branch restrictions if your repository is owned by an organization using {% data variables.product.prodname_team %} or {% data variables.product.prodname_ghe_cloud %}.
{% endif %}
When you enable branch restrictions, only users, teams, or apps that have been given permission can push to the protected branch. You can view and edit the users, teams, or apps with push access to a protected branch in the protected branch's settings.
You can only give push access to a protected branch to users, teams, or installed {% data variables.product.prodname_github_apps %} with write access to a repository. People and apps with admin permissions to a repository are always able to push to a protected branch.
Allow force pushes
By default, {% data variables.product.product_name %} blocks force pushes on all protected branches. When you enable force pushes to a protected branch, anyone with at least write permissions to the repository can force push to the branch, including those with admin permissions. If someone force pushes to a branch, the force push may overwrite commits that other collaborators based their work on. People may have merge conflicts or corrupted pull requests.
Enabling force pushes will not override any other branch protection rules. For example, if a branch requires a linear commit history, you cannot force push merge commits to that branch.
{% ifversion ghes or ghae %}You cannot enable force pushes for a protected branch if a site administrator has blocked force pushes to all branches in your repository. For more information, see "[Blocking force pushes to repositories owned by a user account or organization](/enterprise/{{ currentVersion }}/admin/developer-workflow/blocking-force-pushes-to-repositories-owned-by-a-user-account-or-organization)."
If a site administrator has blocked force pushes to the default branch only, you can still enable force pushes for any other protected branch.{% endif %}
Allow deletions
By default, you cannot delete a protected branch. When you enable deletion of a protected branch, anyone with at least write permissions to the repository can delete the branch.


Sending Client Side Certificate via Client generated by go-swagger.

Problem statement
I am not able to figure out how I can send client side certificate with a testing client I have created using the client generated by go-swagger. My call to the API is failing with status 400 as it expects a client side certificate to be sent as part of the request.
Steps to reproduce
Below is my testing client. I just need a way to pass the client side certificate as part of the request.
ctx, cancel := context.WithTimeout(context.Background(), 100*time.Second)
	defer cancel()

	// create the API client
	client := apiclient.New(httptransport.New("host:port", "basePath", nil), strfmt.Default)

	resp, err := client.Operations.GetLiveness(&operations.GetLivenessParams{Context: ctx})
	fmt.Println(resp)

Environment
swagger version: 2.0
go version: 1.12
OS: macOS 10.14

You make one of these:
https://github.com/go-openapi/runtime/blob/master/client/runtime.go#L154
and set it as a transport on the client

@casualjim - Thanks a lot for the prompt response. Please help me understand the your suggestion:

I should still use go-swagger to generate go client via swagger.yaml. Right?
runtime.go that you pinged above can be used as a testing client to test my service endpoints with the client side certificate. Right? OR I need to use only certain part of the runtime.go in my testing client which I pasted in my issue?

Please correct me if my understanding is wrong.

You make one of these:
https://github.com/go-openapi/runtime/blob/master/client/runtime.go#L154
and set it as a transport on the client

Hi @casualjim  How do we create this and set in aboove client.The SETTransport method take object of type ClientTransport.
I need to set the below value to transport
tr := &http.Transport{
TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
}

Here is an example of what I did:
import (
...
	"crypto/tls"

	httptransport "github.com/go-openapi/runtime/client"
	"github.com/hashicorp/go-cleanhttp"
...
)

// Create a new go-swagger transport
clientTransport := httptransport.New(cfg.Host, cfg.BasePath, cfg.Schemes)
// Init a Go transport
httpTransport := cleanhttp.DefaultTransport()
// Create & set your TLS config
httpTransport.TLSClientConfig = &tls.Config{}
clientTransport.Transport = httpTransport

This should be done through a custom template (specifically, the clientFacade one) so that the changes are not lost when you generate the client.


basic info2

👷 Deploy Preview for hongdeyu processing.

Name
Link

🔨 Latest commit
0af4ef8b1b3a0c2a94339a38d468b4e195d92eae

🔍 Latest deploy log
https://app.netlify.com/sites/hongdeyu/deploys/670c0337ea72ca0008a6b706


[Azure Maps] - Onboarding for Timezone SDK

Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[X] The pull request does not introduce [breaking changes]
[X] CHANGELOG is updated for new features, bug fixes or other significant changes.
[X] I have read the contribution guidelines.

General Guidelines and Best Practices

[X] Title of the pull request is clear and informative.
[X] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[X] Pull request includes test coverage for the included changes.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-maps-timezone

/azp run python - maps - tests

/azp run python - maps - cu

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests

/azp run python - maps - tests