Repository signing key is relatively weak (1024-bit DSA)

The key that is used to sign the Release file / Debian packages in the apt repository at http://download.jitsi.org/ is a 1024-bit DSA key dating from 2008, when Jitsi was known as SIP Communicator.
(1) SIP Communicator (Debian package<EMAIL_ADDRESS>      1024 bit DSA key 0xC697D823EB0AB654, created: 2008-06-20

Today, in 2016, 1024-bit DSA is generally regarded as being uncomfortably close to that which might be able to be cracked by a well-resourced attacker with lots of computational resources.
In addition, there could possibly be concerns about how the private key has been managed over the years, how many online systems it's lived on, etc. Keeping the private key offline or on an air-gapped system, or on a smartcard, would be ideal, but it's also prudent to rotate signing keys after so many years (in this case, 8).
Software like Jitsi supports encrypted protocols like ZRTP/SRTP and OTR, making it appealing to communities with a need for secure communications. These people also would love to see the processes behind the delivery, verification and installation of your software be as "secure" as possible.
In conclusion, I recommend that Jitsi generate a new signing key, ideally 4096-bit RSA.

+1
----- Am 14. Jan 2016 um 1:01 schrieb Kevin M. Gallagher<EMAIL_ADDRESS>
The key that is used to sign the Release file / Debian packages in the apt
repository at http://download.jitsi.org/ is a 1024-bit DSA key dating from
2008, when Jitsi was known as SIP Communicator.
(1) SIP Communicator (Debian package<EMAIL_ADDRESS>1024 bit DSA key 0xC697D823EB0AB654, created: 2008-06-20
Today, in 2016, 1024-bit DSA is generally regarded as being uncomfortably close
to that which might be able to be cracked by a well-resourced attacker with
lots of computational resources.
In addition, there could possibly be concerns about how the private key has been
managed over the years, how many online systems it's lived on, etc. Keeping the
private key offline or on an air-gapped system would be ideal, but it's also
prudent to rotate signing keys after so many years (in this case, 8).
Software like Jitsi supports encrypted protocols like ZRTP/SRTP and OTR, making
it appealing to communities with a need for secure communications. These people
also would love to see the processes behind the delivery, verification and
installation of your software be as "secure" as possible.
In conclusion, I recommend that Jitsi generate a new signing key, ideally
4096-bit RSA.
—
Reply to this email directly or view it on GitHub .

dev mailing list
<EMAIL_ADDRESS>Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Mit freundlichen Grüssen / Kind regards
Rainer Schuth
VNC - Virtual Network Consult GmbH
Professional Services
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
VNC - Virtual Network Consult AG
Poststr. 24, CH - 6301 Zug
Tel.: +41 (41) 727 52 00
Fax: +41 (41) 727 52 09

What will happen if we change the key on the current repository? I mean
what will the user see, a user which had already add the old key?
On Wed, Jan 13, 2016 at 6:01 PM, Kevin M. Gallagher <
<EMAIL_ADDRESS>wrote:

The key that is used to sign the Release file / Debian packages in the apt
repository at http://download.jitsi.org/ is a 1024-bit DSA key dating
from 2008, when Jitsi was known as SIP Communicator.
(1) SIP Communicator (Debian package<EMAIL_ADDRESS>1024 bit DSA key 0xC697D823EB0AB654, created: 2008-06-20
Today, in 2016, 1024-bit DSA is generally regarded as being uncomfortably
close to that which might be able to be cracked by a well-resourced
attacker with lots of computational resources.
In addition, there could possibly be concerns about how the private key
has been managed over the years, how many online systems it's lived on,
etc. Keeping the private key offline or on an air-gapped system would be
ideal, but it's also prudent to rotate signing keys after so many years (in
this case, 8).
Software like Jitsi supports encrypted protocols like ZRTP/SRTP and OTR,
making it appealing to communities with a need for secure communications.
These people also would love to see the processes behind the delivery,
verification and installation of your software be as "secure" as possible.
In conclusion, I recommend that Jitsi generate a new signing key, ideally
4096-bit RSA.
—
Reply to this email directly or view it on GitHub
https://github.com/jitsi/jitsi/issues/203.

Seems like it might require some time where there are two official repositories, one with the old key, one with the new key.

So yeah, the key transition here will be tricky. I've just experimented with signing the "Release" file in an apt repository with two different keys, but that isn't a solution since both keys are required to be present in the apt keyring in order to verify, and even then it's read as invalid/bad.
It appears that on http://download.jitsi.org/nightly, every package is individually signed, rather than the contents of the whole repo (i.e. the Release file I just referred to). I'm not as familiar with this type of setup personally—also not sure how the repo is being generated or how the signing is performed.
Switching the repository signing key, without users updating their keyring, will obviously result in errors. The user will see the message "The following signatures couldn't be verified because the public key is not available" when they run apt-get update. If they attempt to proceed with installation, they'll see WARNING: The following packages cannot be authenticated! and a prompt asking them if they want to proceed without verification.
I am not sure if it makes sense to maintain two repositories during the transition period.
If the Jitsi maintainers want to move forward with transitioning to a stronger key, then it's going to hurt a little. Things will be broken for many people for a while. Admins will begin to see these errors and will hopefully realize that action is required. Other projects have done this before, however, so don't be dismayed.
The best thing that can be done is to prepare for this as fully as possible.

Publish a key transition statement, announcing the new key, and providing a couple commands that people can be copy&paste into their shell to update it. (i.e. sudo apt-key adv --recv-keys KEYID)
Give advance notice (at least a month) to the community, users and developers through as many avenues as possible. Make the notice prominent on the website, GitHub etc.
Switch the signing key and re-sign all of the packages in the repository.
After a little more time has passed, you can revoke the old key or set it to expire, then propagate the expiry or revocation to keyservers.

If you anticipate that a future key transitions may be necessary again, then encouraging people to install a keyring package (one such example here) alongside their software, which updates the signing key in the apt keyring when that package itself gets updated, could make all this less of a headache.

Can't the new key be added to the local repo while the server repo is still signed with the old one?

As I noted earlier, the Jitsi developers have chosen to sign packages individually instead of signing the 'Release' file in the repository, which is unconventional I believe. This results in the following error if you add the repo without having the key:
W: The repository 'http://download.jitsi.org/deb unstable/ Release' is not signed.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.

It also appears that right now (1/20/16) things are in a weird state, or the latest packages are unsigned. When I just installed Jitsi from 'deb/unstable', with the signing key definitely in my apt keyring, apt could not find a signature and prompted me to install without verification.
In a previous comment, I also mentioned the utility of a keyring package. It seems that there is already a SIP communicator keyring .deb which I hadn't noticed.

In apt 1.2.11, there is also a warning about the SHA1 digest algorithm used in the Release.gpg signature.

Here's the present error being thrown by the unstable repo.
W: GPG error: http://download.jitsi.org/deb unstable/ Release: The following signatures were invalid: 040F57608F84BAF1BF844A62C697D823EB0AB654
W: The repository 'http://download.jitsi.org/deb unstable/ Release' is not signed.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Yep this is the old repo which is not used anymore. Try this one:
deb https://download.jitsi.org unstable/


[FEATURE] Turning players into zombies after a successful infection.

I think during the walking dead modpack days there was a feature that implemented zombies infecting players that after a successful infection they would too turn into a zombie with loaded weapons and items which the only way to retrieve your items was to kill them. Also, this could be your first special zombie which cannot despawn.

I actually turned this into a mod of it's own
https://www.curseforge.com/minecraft/mc-mods/zombified-player
I just released the first beta version of the mod. It would be very cool if you could have a look and test this new mod as well. :)

It currently spawns a zombified player no matter how the player dies, but that is why it's beta :)

The latest release includes new config options, e.g. to only spawn a Zombie Player if killed by a Zombie :)

sorry for the late reply, i've been testing this mod and I think it's already perfect condition. ❤❤❤


Numbered and bullet list not workig

Hi, copied everything as you said. All works just the numbered and bullet list does not work
Also the formatting heading,para etc does not work. any solutions ?

did you get it working?

Nope, not working


Feature/657- Module for creating storage account management policy

Overview
This module contains all the code needed for the storage account management policy. A few notes:
Code Structure

I do not loop through the management_policies block since users can only have one management_policy (modules/storage_account/storage_account.tf).
I nest my blocks one level deeper due to the dynamic block. For example, in examples/storage_accounts/107-storage-account-management-policy/configuration.tfvars, line 51, 52:

I tried to simply loop through base_blob, but in modules/storage_account/management_policy/management_policy.tf lines 31 and 32, I am unable to use the dynamic block to validate that base_blob exists and loop through it. Therefore I must have a buffer called blob_specs.
If there is a cleaner way to do this please let me know. Currently, the extra layer is annoying me but I was unable to find a cleaner solution.

This PR is not ready, please do not merge. I have found a bug that needs to be resolved.

Bug resolved. I had commented out the code that validated whether or not a management_policy block existed.

Looks good to me, in a future version, we probably want to have a management_policies specified separately at associated to a storage account via object key.


Light mode: fetch reward account balances

Issue Number
ADP-1422, ADP-1506
Overview
Light-mode (Epic ADP-1422) aims to make synchronisation to the blockchain faster by trusting an off-chain source of aggregated blockchain data.
In this pull request, I have implemented two functions of the NetworkLayer interface:

getCachedRewardAccountBalance
fetchRewardAccountBalances

bors r+

bors r+


Do not clear input when disabled

Closes carbon-design-system/carbon-components-angular#2946
When clicking the clear button, check if the component is disabled before clearing the input.
Changelog
Changed

ComboBox: do not clear input when component is disabled

I have read the DCO document and I hereby sign the DCO.


[Feature] Allow password fill using a password manager

Feature description
Currently https://getalby.com/login can be filled from a password manager (Bitwarden, for example).
Extension drop down and pop up windows must be using different URLs so the password manager does not recognize it and can't offer to fill anything. Workaround: separately open the password manager extension, find Alby, copy password (which I keep long and complex), then look again for the Alby pop up (which is now behind the browser window) and paste.
Describe the solution
https://bitwarden.com/help/uri-match-detection/ What is the Alby extension base domain that would enable recognition by the password manager for a login match?
I can add it manually to my password manager so it starts offering the option of a password fill into the Alby extension.
Describe alternatives
Keep the Alby password simple to remember and type in manually every single time. I don't like this option.
Additional context
I checked https://github.com/getAlby/lightning-browser-extension/blob/master/static/views/popup.html but didn't understand most of it. I'm not that good :)
Are you working on this?
None

Thank you. I looked through "page source" and the location bar shows chrome-extension://iokeahhehimjnekafflcihljlcjccdbe/prompt.css?b64e8ea5cdb46ab290a2 but unfortunately no part of it as a bitwarden URI works to recognize the popup for auto fill.
Also inspected the popup element and the address was chrome-extension://iokeahhehimjnekafflcihljlcjccdbe/popup.html but still didn't work as a URI.
Based on your screenshots, did it work for you? I still get no matching logins.

Awesome, glad I could help! (auto-fill doesn't work by design as extensions can't inject scripts into other extensions)


Plugin keeps iterating across port numbers

Describe the bug
We're using rush to manage a monorepo with several packages.
We're having a fair bit of problems with the vitest plugin.
One of the symptoms is that it keeps complaining that ports are in use, that aren't:
(short excerpt of longer log)
[Worker] Port 5197 is in use, trying another one...
[Worker] Port 5227 is in use, trying another one...
[Worker] Port 5228 is in use, trying another one...
[Worker] Port 5222 is in use, trying another one...
[Worker] Port 5198 is in use, trying another one...
[Worker] Port 5199 is in use, trying another one...
[Worker] Port 5229 is in use, trying another one...
[Worker] Port 5235 is in use, trying another one...
[Worker] Port 5230 is in use, trying another one...
[Worker] Port 5247 is in use, trying another one...
[Worker] Port 5200 is in use, trying another one...
[Worker] Port 5223 is in use, trying another one...
[Worker] Port 5231 is in use, trying another one...
[Worker] Port 5248 is in use, trying another one...
[Worker] Port 5236 is in use, trying another one...
[Worker] Port 5237 is in use, trying another one...
[Worker] Port 5249 is in use, trying another one...
[Worker] Port 5232 is in use, trying another one...
[Worker] Port 5238 is in use, trying another one...
[Worker] Port 5233 is in use, trying another one...
[Worker] Port 5250 is in use, trying another one...
[Worker] Port 5239 is in use, trying another one...
[Worker] Port 5224 is in use, trying another one...
[Worker] Port 5251 is in use, trying another one...
[Worker] Port 5234 is in use, trying another one...
[Worker] Port 5240 is in use, trying another one...
[Worker] Port 5225 is in use, trying another one...
[Worker] Port 5201 is in use, trying another one...
[Worker] Port 5235 is in use, trying another one...
[Worker] Port 5252 is in use, trying another one...
[Worker] Port 5241 is in use, trying another one...

Another is that we keep seeing tons of node processes.

It also creates .mjs timestamp files in the actual source tree that sometimes get left behind.
Reproduction
Install and enable vitest plugin.
Open monorepo workspace with several sub-projects.
Optional: Do git checkout operations that create/delete directories/projects.
Output
[Worker] Port 5197 is in use, trying another one...
[Worker] Port 5227 is in use, trying another one...
[Worker] Port 5228 is in use, trying another one...
[Worker] Port 5222 is in use, trying another one...
[Worker] Port 5198 is in use, trying another one...
[Worker] Port 5199 is in use, trying another one...
[Worker] Port 5229 is in use, trying another one...
[Worker] Port 5235 is in use, trying another one...
[Worker] Port 5230 is in use, trying another one...
[Worker] Port 5247 is in use, trying another one...
[Worker] Port 5200 is in use, trying another one...
[Worker] Port 5223 is in use, trying another one...
[Worker] Port 5231 is in use, trying another one...
[Worker] Port 5248 is in use, trying another one...
[Worker] Port 5236 is in use, trying another one...
[Worker] Port 5237 is in use, trying another one...
[Worker] Port 5249 is in use, trying another one...
[Worker] Port 5232 is in use, trying another one...
[Worker] Port 5238 is in use, trying another one...
[Worker] Port 5233 is in use, trying another one...
[Worker] Port 5250 is in use, trying another one...
[Worker] Port 5239 is in use, trying another one...
[Worker] Port 5224 is in use, trying another one...
[Worker] Port 5251 is in use, trying another one...
[Worker] Port 5234 is in use, trying another one...
[Worker] Port 5240 is in use, trying another one...
[Worker] Port 5225 is in use, trying another one...
[Worker] Port 5201 is in use, trying another one...
[Worker] Port 5235 is in use, trying another one...
[Worker] Port 5252 is in use, trying another one...
[Worker] Port 5241 is in use, trying another one...

### Version

v1.0.4

### Validations

- [X] Check that you are using the latest version of the extension
- [X] Check that there isn't [already an issue](https://github.com/vitest-dev/vscode/issues) that reports the same bug to avoid creating a duplicate.
- [X] Check that this is a concrete bug. For Q&A open a [GitHub Discussion](https://github.com/vitest-dev/vscode/discussions) or join our [Discord Chat Server](https://chat.vitest.dev).
- [X] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.

These are not all the extension logs. You are describing several issues but showing probably the least useful part of logs.

There were performance changes made in 1.2 and onwards. I hope they fix your issues.


Revert "Revert "[Resolver] Turn on parallel cloning by default""

Reverts apple/swift-package-manager#1200

@swift-ci please smoke test


Greedy converters

Summary
Currently converters can only take one of a particular object at one time. It would be good for there to be some sort of greedy converter functionality, similar to d.py, that could take multiple of a single object type and put it in a list.
Problem
See above.
Ideal implementation
async def command(self, ctx, targets: lightbulb.greedy_member_converter):
    print(type(targets))

# Output:
<class 'list'> (or even tuple)

Or something like that. I'll leave you to decide how you think it would work best.
Checklist

[x] I have searched the issue tracker and have made sure it's not a duplicate.
If it is a follow up of another issue, I have specified it.

maybe lightbulb.greedy(lightbulb.member_converter) so it's not needed to create every converter twice. not sure if this is possible tho

maybe lightbulb.greedy(lightbulb.member_converter) so it's not needed to create every converter twice. not sure if this is possible tho

This sounds convenient, it's totally possible. But, I'm hoping this can be implemented as class types as mypy would complain about the invalid typehint.

As I already mentioned in the discord, I would just subclass typing.Generic, I don't think mypy will complain about that.
Something like this looks clean and nice:
async def command(ctx: Context, targets: lightbulb.Greedy[lightbulb.member_converter]) -> None: ...```

As I already mentioned in the discord, I would just subclass typing.Generic, I don't think mypy will complain about that.
Something like this looks clean and nice:
async def command(ctx: Context, targets: lightbulb.Greedy[lightbulb.member_converter]) -> None: ...

I did mean all the built-in converters. Such as lightbulb.member_converter which is a function.


Always set Py_SHARED when building for Windows

Setting PYO3_NO_PYTHON results in an extension module built with
a different config feature set (on Windows).
Specifically, Py_SHARED config option gets omitted in this code path.
Maturin always sets PYO3_NO_PYTHON when cross-compiling abi3 extensions,
which creates a subtle configuration mismatch between cargo build
and maturin build artifacts.
Always set Py_SHARED when compiling abi3 extensions for Windows.

Hmm but PYO3_NO_PYTHON should not be used for Windows, I think...

Well, it may be used, provided that the Python DLL import library path is somehow supplied separately via RUSTFLAGS.
It's even mentioned in the user guide:
https://pyo3.rs/v0.13.2/building_and_distribution.html
Maturin does just that when cross-compiling abi3 extensions for Windows.
See the comments I moved into the condition block:
they led me to believe that this use case was already supported.
I just changed the config defaults so that cargo build and maturin build yield consistent results
whether PYO3_NO_PYTHON  is set or not.

Thanks!


Incoming app model changes for preview 4.

As part of preview 3 we are making a number of signifcant API changes based on the learnings from earlier previews. The purpose of this issue is to track implementation of these changes:

[x] Resources such as Postgres, Redis etc that have release quality containers will have a single resource type (e.g. PostgresResource) which derives from ContainerResource. We used this model in Preview 1, change it for preview 2, but will revert to the approach in preview 3. The purpose for this change is to make it easier and more obvious for developers to customize how these containers work locally ... these local customizations will not necessarily apply to these resources when they are deployed to cloud environments via deployment tools.
[x] Resources that run as a container locally, but are automatically converted to a an abstract resource (e.g. AddPostgres becomes postgres.server.v0 in the manifest) will have a PublishAsContainer(...) method with a callback which replaces the manifest writing callback with a standard container writer callback.
[x] UseEmulator(...) methods will support a callback which provides a ContainerResource (a wrapper on top of the underlying abstract resource) so that emulator containers can be customized. This is only necessary in cases where we have an abstract resource such as Azure Storage or Azure Cosmos and container emulation is opt in.

Here is a snippet of code that illustrates some of these concepts:
var pgsql = builder.AddPostgres("mypostgres") // Returns a PostgresResource (defaults to container when running, managed when publishing)
                   .PublishAsContainer(); // just replaces the publishing callback annotation

var storage = builder.AddAzureStorage("s")
                     .UseEmulator(c => // adds annotations that impact the container when running
                     {
                        c.WithEnvironment("POSTGRES_DB", "TodosDatabase");
                        c.WithVolume(...);
                        c.WithImage("MyCustomPostgres");
                        c.WithTag("v3.4");
                     });

This should all be done now.


Unknown Parameter for value key: LOWBAT

Description of problem:
Error log messages during Home Assistant startup:
[pyhomematic.devicetypes.generic] HMGeneric.getValue: LOWBAT on 00109709A8F405:1 Exception: <Fault -5: 'Unknown Parameter for value key: LOWBAT‘>
Home Assistant version: 0.82.1

What type of device is this?

It comes form Window / Door Sensor. Homematic IP Fenster- und Türkontakt - optisch HMIP-SWDO and HmIP-SWDO-I

Am 18.11.2018 um 16:52 schrieb Daniel Perna<EMAIL_ADDRESS>What type of device is this?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/danielperna84/pyhomematic/issues/186#issuecomment-439702867, or mute the thread https://github.com/notifications/unsubscribe-auth/ASbx0OAxzViUBrhudZPW_-yvDJn031okks5uwYIigaJpZM4Yn_on.

Could you please check if your device is using the parameter LOW_BAT instead of LOWBAT?
This is how to do that:
from xmlrpc.client import ServerProxy
p = ServerProxy("http://ccu-ip:2010")
# Should return True or False, depending on the battery state
p.getValue("00109709A8F405:1", "LOW_BAT")

Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/xmlrpc/client.py", line 1092, in call
return self.__send(self.__name, args)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1432, in __request
verbose=self.__verbose
File "/usr/lib/python3.5/xmlrpc/client.py", line 1134, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1150, in single_request
return self.parse_response(resp)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1322, in parse_response
return u.close()
File "/usr/lib/python3.5/xmlrpc/client.py", line 655, in close
raise Fault(**self._stack[0])
xmlrpc.client.Fault: <Fault -5: 'Unknown Parameter for value key: LOW_BAT'>

Am 18.11.2018 um 17:07 schrieb Daniel Perna<EMAIL_ADDRESS>Could you please check if your device is using the parameter LOW_BAT instead of LOWBAT?
This is how to do that:
from xmlrpc.client import ServerProxy
p = ServerProxy("http://ccu-ip:2010")
Should return True or False, depending on the battery state
p.getValue("00109709A8F405:1", "LOW_BAT")
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/danielperna84/pyhomematic/issues/186#issuecomment-439703984, or mute the thread https://github.com/notifications/unsubscribe-auth/ASbx0AFiTN7jM7SEf3H5I0-M0gDTw5F7ks5uwYW8gaJpZM4Yn_on.

Ok, then please post the output of datapoints.py as a gist.

https://gist.github.com/FlavorFx/9427fee3d5d57c802c61fc52b099d647 https://gist.github.com/FlavorFx/9427fee3d5d57c802c61fc52b099d647
ok, here we are.

Am 18.11.2018 um 17:18 schrieb Daniel Perna<EMAIL_ADDRESS>Ok, then please post the output of datapoints.py https://github.com/danielperna84/pyhomematic/blob/master/datapoints.py as a gist https://gist.github.com/.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/danielperna84/pyhomematic/issues/186#issuecomment-439704806, or mute the thread https://github.com/notifications/unsubscribe-auth/ASbx0PsIr-jg8tUEJ5MT0szh2gTExLmwks5uwYhwgaJpZM4Yn_on.

I had a look at it now. This should get the result:
from xmlrpc.client import ServerProxy
p = ServerProxy("http://ccu-ip:2010")
# Should return True or False, depending on the battery state
p.getValue("00109709A8F405:0", "LOW_BAT")

Correct. It works! It returns FALSE because non if my devices are low of batterie. Are you going to fix this in the next release?

Am 23.11.2018 um 21:07 schrieb Daniel Perna<EMAIL_ADDRESS>I had a look at it now. This should get the result:
from xmlrpc.client import ServerProxy
p = ServerProxy("http://ccu-ip:2010")
Should return True or False, depending on the battery state
p.getValue("00109709A8F405:0", "LOW_BAT")
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/danielperna84/pyhomematic/issues/186#issuecomment-441311760, or mute the thread https://github.com/notifications/unsubscribe-auth/ASbx0NiRI8oSBBYLhF649Q00aFcVF_KGks5uyFWHgaJpZM4Yn_on.


513 Deprecating Legacy Plot API

Describe your changes

Added deprecation warnings for legacy plot functions: .pie(), .bar(), and .plot()
Added tests for deprecation warning messages
Merged from master instead of individual branch

Issue number
Closes #513
Checklist before requesting a review

[x] Performed a self-review of my code
[x] Formatted my code with pkgmt format
[x] Added tests (when necessary).
[x] Added docstring documentation and update the changelog (when needed)

:books: Documentation preview :books:: https://jupysql--870.org.readthedocs.build/en/870/

I was able to identify and fix the matplotlib bug. The tests I wrote in test_resultset.py were interfering with those in test_util.py. After re-writing my tests all checks are passed.

@bryannho no need to respond to the PR comments when you begin working on stuff. it's fine if you respond to them after you finished the changes


Prod product could not be created

Unable to create a new product

The feature already exists

The latest version of this feature is available


error running for the first time

I am trying to run for the first time and I keep getting an error.
When I run:
gpt-engineer projects/my-new-project
I get:
Traceback (most recent call last):
File "C:\Users\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 196, in _run_module_as_main
return _run_code(code, main_globals, None,
File "C:\Users\AppData\Local\Programs\Python\Python310\lib\runpy.py", line 86, in run_code
exec(code, run_globals)
File "C:\Users\AppData\Local\Programs\Python\Python310\Scripts\gpt-engineer.exe_main.py", line 4, in
ModuleNotFoundError: No module named 'gpt_engineer'
I appreciate all the help and any suggestions you might have.
Thank you,
Miguel

You need to run as following
python -m gpt_engineer.main my-new-project

Thank you I got it working I had to uninstall all the pythons reinstall it and update the path

I think you have forgot to install the library.


Not able to have animation tilt with masked image?

Can you make it that you can tilt the fluid while its on a masked image?

Yup that's possible. Here's a gist with an example:
https://gist.github.com/antiguab/879eff6200aee9396f3b


Very Confused How do I download the ZIP?

Go to releases, download it from there.

Go to releases, download it from there.


Adding support for german translation (on crowdin)

Hey, I recently found out about this project and noticed that it doesn't have german support rn.
I'm interested in providing a german translation but I saw that german isn't available in the crowdin project yet.
I've sent a request dm on crowdin but there was no reaction yet, maybe they missed it - so I decited to now try it here.
PS: I already started by adding a de-de.json to my local installation. It works fine. The launcher even automatically gets the image resources in german now nice as seen in the genshin wish bg for phase 2.

I have fun translating stuff but I saw that an other person (#125) is already working on a german translation which has first far more progress and also has at many points by far better wordings then mine so I gonna stop on my work now. But still I would like to see german finally added to crowdin so for current and future translations you can have a better workflow.

PS: Sry my english writing skills aren't the best but I do understand it pretty well tho c:
Also I gonna take @DasIschBims's translation and replace it with my local de-de.json file so I can use the launcher in german now.

since DaslschBims already working on it in their own fork, I think we can wait for them.
There are 2 options right now,

Wait for DaslschBims to finish the translation and then merge its PR, or
DaslschBims  can give or commit their latest de-DE.json, then we upload them to Crowdin after that both of you can help translating strings to German.
Both of them are valid options, I'll wait for @neon-nyan to pick an option.
Since we also planning to implement HSR Game Settings in the next major version, there will be more strings to translate. Though most of them are copies from HI3 Game Settings locale so it shouldn't take too long.

Hi @kujou-kju,
Thank you for your interest on the localization and sorry for my late reply since I don't feel well for a few days recently.
As per information by @bagusnl, we have two choices for both of you to join the latest PR or waiting for us to add Daslsch's latest commit to Crowdin as we just added the language.
But for me, we can have the second option to be applied since both on you could collaborate together on the localization.
I'm now adding the latest commit of the PR to Crowdin.


Ignore dev-dependencies

Charon appears to expect dev-dependencies to be compiled, i.e. running cargo build is not enough.
If this is intentional, the recommendation should be changed to run cargo build --tests or a switch could be added to not look at tests.

Thanks for this useful remark! According to what you write, I understand you tested with cargo build --tests and it worked? Which dependencies were concerned by this?

Yes, building with tests solves the issue somewhat (see my comment in #3).

Which dependencies were concerned by this?

Charon appears to expect all dependencies (dependencies and dev-dependencies, I didn't test others) to be built.

Charon now works with cargo so I'm closing this issue which is obsolete.


Replace to_sql() with copy_expert() to improve performance while savi…

Improving performance while saving data in Postgresql in case of large dataset.
to_sql() method is slow and takes times to save data in Postgres. It is replaced with copy_exprt() to save data in Postgres tables fast.

I also added one commit to parallelize compute_norm_cond_entropy_corr() method.
With single thread on hospital data, it takes 3.11 sec. With 6 threads, it takes 1.05 sec on my mac (16GB RAM)


Next iteration of spreadsheet-style bulk editor

The first iteration of the bulk editor tool provides a grid-based view to edit the profile fields of selected Data Elements from a Data Model.  This Epic defines some tasks for the next iteration of this functionality - improving its usability and making it more applicable across the rest of Mauro.  There's one ticket for each task, but these may need to be broken down into sub-epics if necessary
Tasks

[x] #577
[x] #578
[x] #579
[x] #580
[x] #581
[x] #582
[x] #583
[x] #584
[x] #585

Related

MauroDataMapper/docs#63

All tasks have been completed in this epic now.


fix TypeError preventing bids in the dapp

This fixes #193.
#193 prevents bids due to a TypeError. The likelihood that newBid fails appears to increase as time passes. As documented in #193, a launch ratio of 3.2100486588541655 causes randomName to throw a TypeError ~69% of the time.

@alexvandesande ptal

Closing; this is redundant with https://github.com/ethereum/ens-registrar-dapp/pull/196.

Sorry, I didn't see this one! The one I approved didn't include a rebuild - would you be prepared to submit one that does?


Inline rules expand ambiguities unnecessarily

Thanks for fixing #1214 earlier. It now seems to return all ambiguities, but ambiguities inside inline rules are expanded within the parser rather than leaving it to CollapseAmbiguities transformer.
I have some input strings that explode very quickly when expanding ambiguities. I parse them with ambiguity=explicit, then count the expected number of expanded ambiguities. If it's within a reasonable threshold, I put the tree through CollapseAmbituities. Otherwise, the processing stops (until I find a better way to deal with such strings). As the result, I still can't use inline rules because parsing of some inputs explodes before I can even count the number of ambiguities.
To reproduce, parse this string:
t = parser.parse('1 2 3')
print(t.pretty())

with this grammar
start: field+
field: f1 | f2

f1: INT
f2: INT

%ignore WS
%import common.WS
%import common.INT

Result:
start
  _ambig
    field
      f1	1
    field
      f2	1
  _ambig
    field
      f1	2
    field
      f2	2
  _ambig
    field
      f1	3
    field
      f2	3

Now, inline field:
start: _field+
_field: f1 | f2

f1: INT
f2: INT

%ignore WS
%import common.WS
%import common.INT

The parser now expands the nested ambiguities prematurely:
_ambig
  start
    f1	1
    f1	2
    f1	3
  start
    f1	1
    f1	2
    f2	3
  start
    f1	1
    f2	2
    f1	3
  start
    f1	1
    f2	2
    f2	3
  start
    f2	1
    f1	2
    f1	3
  start
    f2	1
    f1	2
    f2	3
  start
    f2	1
    f2	2
    f1	3
  start
    f2	1
    f2	2
    f2	3

@chanicpanic The saga continues!

Sorry, messed up the original examples, corrected now.

The example provided is actually a special case that may be open to optimization. Consider the general case in which expansions of field may contain more than one rule:
start: field+
field: f1 ws | f2 ws2

f1: INT
f2: INT
ws: WS
ws2: WS

%import common.WS
%import common.INT

Parsing the text "1 2 3 " produces:
start
  _ambig
    field
      f1        1
      ws
    field
      f2        1
      ws2
  _ambig
    field
      f1        2
      ws
    field
      f2        2
      ws2
  _ambig
    field
      f1        3
      ws
    field
      f2        3
      ws2

If we inline field in this tree, we get:
start
  _ambig
    f1        1
    ws
    f2        1
    ws2
  _ambig
    f1        2
    ws
    f2        2
    ws2
  _ambig
    f1        3
    ws
    f2        3
    ws2

which is not correct. In this case, I see no more compact way to represent the ambiguities than to expand them all.
We may be able to optimize the special case in which all instances of _field have a single child. However, it is a tradeoff. It would add complexity during tree building for a smaller tree size. On the other hand, expanding the tree is work that may be done later anyways when collapsing ambiguities.
@yurymann Conditional inlining may be your friend for highly ambiguous rules:
start: field+
?field: f1 | f2

f1: INT
f2: INT

%ignore WS
%import common.WS
%import common.INT

gives:
start
  _ambig
    f1  1
    f2  1
  _ambig
    f1  2
    f2  2
  _ambig
    f1  3
    f2  3

You may also want to look at lark-ambig-tools which can help you process highly ambiguous trees more efficiently.

@chanicpanic, wow, conditional inlining looks indeed like THE solution for my case.
And thanks for the lark-ambi-tools link! Disambiguator is particularly a thing I was looking for and was almost ready to write myself.


Add stubs file to PyAV

Overview
There's currently no .pyi files in the PyAV installation path, which brings much difficulty to the development, as the language server
couldn't resolve any symbols and provides no completion or hints.
Desired Behavior
Add some basic stubs to PyAV, I'm not looking forward to a detailed type hint, just function signature and some documents,
I'd heard that there's some tools like stubgen has the ability to finish the task automatically, but I'm not sure that it will work with Cython files and C module.
Additional context
I'll also try to write the stubs by myself, but I certainly need more help

Hello @RuoXian233,
Would you like to draft a new PR and work on it? I would like to help.


Can't build PyImath_d on Windows without debug Python build

On Windows pyconfig.h automatically links to debug Python builds if _DEBUG is defined:
https://github.com/python/cpython/blob/v3.10.9/PC/pyconfig.h#L270-L271
Boost Python wraps this so that it can be compiled in debug mode without requiring a debug build of Python:
https://github.com/boostorg/python/blob/boost-1.76.0/include/boost/python/detail/wrap_python.hpp#L23-L48
This is the default behaviour and can be controlled using BOOST_DEBUG_PYTHON.
Because PyImath headers include Python.h directly this bypasses the Boost python wrapper causing link incompatibility.
These headers should include boost/python/detail/wrap_python.hpp instead. Other libraries (e.g. USD) wrap BOOST_DEBUG_PYTHON in a cmake option, e.g.: https://github.com/PixarAnimationStudios/USD/pull/1478

This is a reasonable suggestion, we could do that. Are you interested in submitting a PR? I don't personally work with debug python builds on windows, so I'm not really set up to try this locally.


Readme update: add simple syntax description

Thanks! I made the section a bit shorter and added it to the readme.


Disabled dates selectable when changing months.

So, let's say February 2 is in my disabledDates list. Works perfectly. If I switch to March, select March 2, and then switch back to February, the 2nd becomes selected. So it seems like when switching months or years, there needs to be a check against the disabledDates list, and if there's a conflict, select the next non disable date.

Still facing this issue in 2021 😫 any ideas?


fix: Fix UI of ordered ticket item

Fixes #454

please add befor changes screen shot

Before change

Updated

@dreadpool2 As I commented earlier padding is fine. Just fix the width. This way the card looks too big. See how tickets fragment looks in Eventbrite

@nikit19 Please check now :+1:

Removed hardcoding of widths :+1:

PR Udpated.


ORC-767 Add jdk 8 support for the debian 10 docker file

What changes were proposed in this pull request?

Added a command to print the java version from cmake.
Updated the debian10 docker file to support jdk 8 and 11.

How was this patch tested?
They were run manually.

Could you resolve the conflicts, @omalley ?

This is merged via https://github.com/apache/orc/commit/26e63a256294bafb503184dd3122eb43af2beb7b


[Suggest] Call zellij from wezterm instead of call it from fish

Issue:
When launching Zellij from Fish, it creates an additional terminal instance. This forces multiple Ctrl+D inputs to fully exit. However, launching Zellij directly from WezTerm avoids this issue.
Suggested Solution:
In config.fish, remove:
if not set -q ZELLIJ
    zellij
end

in wezterm.lua add:
config.default_prog = { os.getenv("HOME") .. "/.cargo/bin/zellij" }

Love the idea, will test !!
Also remember that in Zellij I have multiple tabs so you need to exit each one if you want to quit or just call the quit shortcut in Zellij


Problem sending files witn \yii\web\Response::xSendFile

I think that xSendFile should set the response format to FORMAT_RAW as do the sendFile, sendContentAsFile and sendContentAsFile methods.
The current implementation does not respect the mime type of the file being send as the "Content-Type" response header is always set to "text/html" since the default response format is set to FORMAT_HTML.

It's a bug in 2.0.3 that's already fixed in master.

@samdark It does not seems to be fixed. Response format still "html". I have latest version 2.0.3. Please check function xSendFile in \yii\web\Response (line 684) - function returns Response object, but $this->format = self::FORMAT_RAW does not set.

Have you checked if it is actually broken?

As I've commented, 2.0.3 has this bug. It is already fixed and will be released with 2.0.4.

@samdark Ok, no problem. Thanks.


You are trying to run a container which is more than 90 days old.

This is the actual situation from which I start, the actual image was just downloaded a couple of minutes ago and there are no running containers based on this image or another.

Write-Host "Creating container..."
$imageName = "mcr.microsoft.com/businesscentral/onprem:14.0.29537.0-be"
New-NavContainer $containername -imageName $imageName -accept_eula  -doNotCheckHealth
    -accept_outdated -licenseFile "C:\TMP\lic.flf" -auth "Windows" -updateHosts -doNotExportObjectsToText -useBestContainerOS

Write-Host "Container running" -ForegroundColor Green

This results in:

Hostname is demodevext1
PublicDnsName is demodevext1
You are trying to run a container which is more than 90 days old.
Microsoft recommends that you always run the latest version of our containers.
PublicDnsName is demodevext1
You are trying to run a container which is more than 90 days old.
Microsoft recommends that you always run the latest version of our containers.
Set the environment variable ACCEPT_OUTDATED to 'Y' if you want to run this container anyway.
at , C:\Run\navstart.ps1: line 54
at , C:\Run\start.ps1: line 121
at , : line 1
Initialization of container demodevext1 failed
At C:\Program Files\WindowsPowerShell\Modules\navcontainerhelper\<IP_ADDRESS>\ContainerHandling\Wait-> NavContainerReady.ps1:45 char:17

...             throw "Initialization of container $containerName failed" ...

            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo          : OperationStopped: (Initialization ...odevext1 failed:String) [], RuntimeException
FullyQualifiedErrorId : Initialization of container demodevext1 failed

Kind of strange since the container is just created this instant moment and can't be 90d old. The image itself might (here not the case) be, but that can't be the problem.
navcontainerhelper version: <IP_ADDRESS>

@StijnBt the error is indeed a bit misleading, the problem actually is that the image is older than 90 days

So I ran it again and started from the situation as below:

Yet I get the same error, in this specific case I want to have docker environment based on mcr.microsoft.com/businesscentral/onprem:14.0.29537.0-be. If this image is "old" and newer CU's exist that's fine, but it should still be possible to run "older" images/cu's for testing purposes. Certainly in OnPrem scenarios or am I missing something obvious completely.

@StijnBt yes, you can do that as the error message also says: Set the environment variable ACCEPT_OUTDATED to 'Y' if you want to run this container anyway. I missed the fact that you have already used -accept_outdated, so this actually should work and seems to me like a bug

I agree, the error is misleadning.
If the script above is an exact copy/paste, then it is missing the tilde (`) at the end of the new-navcontainer and therefore the second line is not seen as a continuation of the first (https://freddysblog.com/2019/08/04/powershell-for-non-experts/).
If that is not the case, please copy/paste the full command and the full output of the new-navcontainer command.
thanks

I agree, the error is misleadning.
If the script above is an exact copy/paste, then it is missing the grave symbol (`) at the end of the new-navcontainer and therefore the second line is not seen as a continuation of the first (https://freddysblog.com/2019/08/04/powershell-for-non-experts/).
If that is not the case, please copy/paste the full command and the full output of the new-navcontainer command.
thanks

Yep... rookie mistake. My bad,


Support mattermost 6.2

Mattermost plugin exits with error due to version 6.2 not being recognized.
Ignoring version works.
Only error (maybe unrelated):
level=error msg="error:websocket: close 1006 (abnormal closure): unexpected EOF" prefix=matterclient

What plugin are you talking about exactly?

matterclient

Could you please give the output where it actually fails?
You're probably using an outdated matterbridge version, there are no version checks anymore since v1.23.1

nevermind, thank you. It was a problem stemming from certificate issues.


dashboard/app: allow fix bisection results to be visible on web UI

Modify the dashboard/app/bug.html template to show fix bisection results.
Modify handleBug() to fetch and create a uiJob for fix bisection results.
Modify loadBisectJob() to fetch jobs based on a specified jobType. Change all callers to pass in jobType info into loadBisectJob().
Add TestBugBisectionResults() to ensure bisection results show up as expected.

Codecov Report

Merging #1307 into master will decrease coverage by 0.03%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #1307      +/-   ##
==========================================
- Coverage    57.7%   57.67%   -0.04%
==========================================
  Files         131      131
  Lines       24646    24659      +13
==========================================
  Hits        14222    14222
- Misses       9750     9763      +13
  Partials      674      674

Impacted Files
Coverage Δ

dashboard/app/main.go
0% <0%> (ø)
:arrow_up:

dashboard/app/reporting.go
0% <0%> (ø)
: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 c692b5b...afe81bf. Read the comment docs.

Overall looks good to me. I will merge this now to not delay things unnecessary. But there is one thing I would like to ask you to fix as a follow up PR. The bisect result presentation code in bug.html looks like almost complete duplicate of the cause bisection result presentation. The only difference seems to be few strings (like "caused" vs "fixed"). The template engine language has block construct that allows to eliminate this kind of duplication. Check out templates.html, it defines a number of such common blocks which can then be invoked from multiple places with different arguments (think of function calls in an imperative language). Please move bisect result rendering code into such block with *dashapi.BisectResult argument. We will also need to add type the dashapi.BisectResult, and then we can do {{if}} on the type and produce "cause" vs "fix" strings based on the type.

Looking at some upstream results, I already see a correctly bisected one:
https://syzkaller.appspot.com/bug?id=341e1a2a55b389e54cc07624ed40eb3ecca577db
We can now go and close it as fixed by the identified commit.
I also see some on the chromeos tree, e.g. "KASAN: use-after-free Read in ipt_do_table". It seems that we can mark it as fixed right away.
This is great!
We need few last things to make it perfect:

In the bugs table:
https://syzkaller.appspot.com/upstream#open
there is "Bisected" column. Currently it shows just "yes" (for cause bisection)". I think we now need to show "cause", or "fix", or "cause+fix" or "" in that column.

We need to be able to mail fix bisection results in emails and in external reporting. As we do for cause results.

This bug:
https://syzkaller.appspot.com/bug?id=f007ef1d7a31a469e3be7aeb0fde0769b18585db
did not happen for 467d, but the bisection suggests that it still happens and still a bug
we should do 2 things for such bugs:
(1) do another fix bisection later
(2) add the bisection crash to the crashes, so that it's clear that it still happens and we have a fresh crash and send a ping for this bug

Overall looks good to me. I will merge this now to not delay things unnecessary. But there is one thing I would like to ask you to fix as a follow up PR. The bisect result presentation code in bug.html looks like almost complete duplicate of the cause bisection result presentation. The only difference seems to be few strings (like "caused" vs "fixed"). The template engine language has block construct that allows to eliminate this kind of duplication. Check out templates.html, it defines a number of such common blocks which can then be invoked from multiple places with different arguments (think of function calls in an imperative language). Please move bisect result rendering code into such block with *dashapi.BisectResult argument. We will also need to add type the dashapi.BisectResult, and then we can do {{if}} on the type and produce "cause" vs "fix" strings based on the type.

Thanks, I'll make this change and put up a PR.

Overall looks good to me. I will merge this now to not delay things unnecessary. But there is one thing I would like to ask you to fix as a follow up PR. The bisect result presentation code in bug.html looks like almost complete duplicate of the cause bisection result presentation. The only difference seems to be few strings (like "caused" vs "fixed"). The template engine language has block construct that allows to eliminate this kind of duplication. Check out templates.html, it defines a number of such common blocks which can then be invoked from multiple places with different arguments (think of function calls in an imperative language). Please move bisect result rendering code into such block with *dashapi.BisectResult argument. We will also need to add type the dashapi.BisectResult, and then we can do {{if}} on the type and produce "cause" vs "fix" strings based on the type.

Thanks, I'll make this change and put up a PR.

Is there any advantage to modifying dashapi.BisectResult? It seems like uiJob has a JobType which can be used for choosing what to render; something like : https://github.com/zsm-oss/syzkaller/commit/e85fb7e09884568597981e1edd2872034bf543e2
I'm not sure if we should use the

{{$causeJob := 1}}
{{$fixJob := 2}}

and instead just pass a "IsBisectCause" as well.

Is there any advantage to modifying dashapi.BisectResult?

You are right. We don't need to touch dashapi.BisectResult.

I'm not sure if we should use the
and instead just pass a "IsBisectCause" as well.

Hard to say. Let's go with your current version.


Support of "-mmacosx-version-min" and MACOSX_DEPLOYMENT_TARGET < current MacOSX

I use brew to build application dependencies to distribute an app. I use MacOSX Sierra (10.12) to build. But the signed build doesn't run on older MacOSX like 10.9. Because "codesign" use the LC_VERSION_MIN_MACOSX entry of the binary to determine which hash code should be created: SHA1 or a SHA-256. Older MacOSX only supports SHA1.
This is what brew currently creates:
  cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.12
  sdk 10.12

This is what is needed:
  cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.9
  sdk 10.12

Is it possible to build all brew packages with custom settings for
-mmacosx-version-min and MACOSX_DEPLOYMENT_TARGET
? Or is there a better way to solve this ?
Thanks

Is it possible to build all brew packages with custom settings for
-mmacosx-version-min and MACOSX_DEPLOYMENT_TARGET

We don't support this, sorry.

? Or is there a better way to solve this ?

Build them yourself outside of Homebrew.


Add 5k Fun Run/Walk Route

Add a polyline geojson file of the 2015 route, as provided by Geoff.

Added the PDF, see commit<PHONE_NUMBER>00989002a221cb9ac3333623711b48

Added the route to the map. See commit aea29796d32034adc3e3764e040a1115cfd6efb5


Handle Gnustep client message event

GNUstep Apps are sending  client message for the _GNUSTEP_WM_ATTR atom.
Actually is not handled. Handle it!

Not needed to be handled


API V3 BETA

Bittrex released on new version of its API ;-)
https://bittrex.zendesk.com/hc/en-us/articles/360027160871-Changelist-04-19-2019
https://bittrex.github.io/api/v3
Thanks

https://bittrex.github.io/guides/v3/upgrade


.net core batch job and pool delete operations fail to authenticate

Having some issues with the the pool and job delete operations when running .net core 1.1, version 6.1.0 of the SDK.
ClientRequestId:
RequestId xxxx
HttpStatusCode:Forbidden
StatusMessage:Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.

Error Code = AuthenticationFailed, Lang=en-US, Message = Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:xxxx
Time:2017-05-05T07:51:18.6188868Z
Additional Values:
Error Details key=AuthenticationErrorDetail value=The MAC signature found in the HTTP request 'xxxx' is not the same as any computed signature. Server used following string to sign: 'DELETE

Getting this error on:

BatchClient.PoolOperations.DeletePoolAsync
batchClient.JobOperations.DeleteJobAsync
BatchClient.PoolOperations.DeletePool
BatchClient.JobOperations.DeleteJob

All the other operations are working, but these two won't authenticate.
Read that this might be a issue with a proxy cache, any way to disable that when running the sdk?
https://social.msdn.microsoft.com/Forums/SqlServer/en-US/67183d62-60ab-4ef0-a1ca-b765d85ea2f6/authenticationfailed?forum=azurebatch
Any quick solutions?

@LeifRoss please provide Nuget package ID and version of the Batch that you use.

@hovsepm
Azure.Batch - 6.1.0 - https://www.nuget.org/packages/Azure.Batch/6.1.0

Hi @LeifRoss - Can you let me know what region you're on and share your RequestId (which was redacted above) with me?
Note: The RequestId isn't a secret, it's an opaque GUID that service developers can use to find your request on our server.

Hi @LeifRoss, I have also been able to reproduce this, I'm currently investigating the cause and will get back to you.

Hi @matthchr
This is the request id: ae21288d-1f8e-42c3-ade2-83b576739cbd
Thanks!

I've tracked down the cause of this. It is due to a bug in our SDK, caused by a subtle behavior change in NetCore. Apparently HttpClient now includes the content-length header implicitly on all POST requests (even if there is no body), but not on DELETE requests.  This is a change from netframework where POST and DELETE both had an implicit content-length even if there was no body.
Because we use the content-length header as part of the shared key header signing process, this change ended up screwing up the signing logic.
I'll include a fix for this and ship it in the next few days. The only workaround that I can see for now would be recompiling the code yourself with the fix.  If that's something that you want to do, I can share the patch with you. Otherwise the fix will be in 7.0.1 whose ETA is sometime next week probably.

Excellent, thank you!

This has been fixed in Azure.Batch 7.0.1. Thanks for the report @LeifRoss

I am encountering this exact same issue with version 8.1.2 of the Azure.Batch running on .net core 2.1.
I was able to create a pool and start a job no problem, but can't delete it. Is it possible this bug is back? Anything I can do to get around it?

It is back, and is being tracked by #4602 - A fix is in PR here #4689 and will be released as 9.0 shortly.


${var} breaks the parser.

Looks like ${var} can break the parser.
         > Hi @pksml85 can I have your example config file to improve [gonginx](https://github.com/tufanbarisyildirim/gonginx)?

Hi @tufanbarisyildirim. Sorry for the delay... but here is the example. GoNginx destroys my location blocks.
Here is my original config code and here is the mangled code from GoNginx
Originally posted by @pksml85 in https://github.com/0xJacky/nginx-ui/issues/73#issuecomment-1528894406

I think a good could be something like;

Separate keywords & vars during the lexing instead of scanning all in 1 keyword
Define a Parameter (at same level with Directive) statement in parser and encapsulate all tokens that creates the parameter.

I think a good plan could be something like;

Separate keywords & vars during the lexing instead of scanning all in 1 keyword
Define a Parameter (at same level with Directive) statement in parser and encapsulate all tokens that creates the parameter.

instead, changed the way we read a keyword, now token.Variable is useless and we need another PR to clean it up.


Display (but not allow editing of) Non-writable properties that are readable

Line 13 of ObjectInput.razor

Fixed in #73


ci(udeps): upgrade actions/checkout to v3

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Docs
[ ] New Binding issue #___
[ ] Code style update
[ ] Refactor
[x] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change?

[ ] Yes, and the changes were approved in issue #___
[x] No

Checklist

[x] When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
[ ] A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
[ ] I have added a convincing reason for adding this feature, if necessary

Other information

I'm confused. Why is this PR closed and labeled as spam?

It does feel like you're trying to spam PRs for hacktoberfest though, there's 24 files with checkout@v2 and 33 occurrences, so you're suggesting 24 PRs (or even 33) for such a small change? This would even waste our CI though which is already not perfect.

We initially wanted to just mark it as invalid because this pr is against the spirit of hacktoberfest, but because of what Lucas said, and the fact that you already opened like 100 similar PRs we went with the spam label instead because this really does look fishy to be completely honest.

It does feel like you're trying to spam PRs for hacktoberfest though, there's 24 files with checkout@v2 and 33 occurrences, so you're suggesting 24 PRs (or even 33) for such a small change?

I'm sorry this is being perceived as spam. If it's felt like that I'm happy to close them.
My intention was to help projects participating in Hacktoberfest to get updated with the latest version of some actions/, something we tend to forget as maintainers. I'm also happy to help set up Renovate, which in my experience works quite good if you want a more automatic solution. I can even create a GitHub Discussion if you are up to talking about that.
My intention was to suggest an upgrade per each file in workflows/, in case there was any kind of problem, it would be more granular to revert but, if you want to do the bump in the same PR, I'm happy to do that as well (it's easier to open one PR than N PRs for me as well).

This would even waste our CI though which is already not perfect.

I'm sorry I was not aware you were using a self-hosted(?) solution for CI, I just assumed you were using the free Tier of GitHub and that opening a few PRs is not a problem. I would be happy to suggest an update in https://github.com/tauri-apps/tauri/blob/dev/.github/CONTRIBUTING.md#pull-request-guidelines to remark this as well.

We initially wanted to just mark it as invalid (or simply close it) because this pr is against the spirit of hacktoberfest

Re-reading the Values it's not clear to me why these contributions are going against the spirit of Hacktoberfest, to be honest. Still, I can close all the PRs I opened in tauri and apologize for the noise these contributions caused to you (and the costs on CI, I was not aware of that part).

, but because of what Lucas said, and the fact that you already opened like 100 similar PRs we went with the spam label instead because this really does look fishy to be completely honest.

I posted in my previous comment my idea and intentions regarding my change. I don't see it as fishy but I guess it depends on the angle you see it.
So... if you want I can close my PR's if that is what you want.
In any case, thanks for your time checking this and I'm so sorry for this feeling of spammy contributions but it was not my intention at all. I just wanted to help and add my small grain of sand.


⚠ Cioos National CKAN Sitemap has degraded performance

In 5899f9a, Cioos National CKAN Sitemap (https://catalogue.cioos.ca/sitemap/sitemap-1.xml) experienced degraded performance:

HTTP code: 200
Response time: 10452 ms

Resolved: Cioos National CKAN Sitemap performance has improved in a328f2d after 16 minutes.


Support environment variable interpolation

This feature could easily be added by allowing the definition of a .env parameter or the like in long-form notation, along with a separate object [env_files] or similar in which the user could define a list of files to pull in environment variables from (in addition to any provided to Bonnie itself on the command line). The system would then fail gracefully if a variable isn't defined.
I think this feature would make developing more complex and integrated systems much easier. For example, if you define Docker ports to be opened in an environment variable file and then interpolate that into docker-compose.yml, if you need to expose those same ports in a docker-compose run command you alias with Bonnie, you should be able to read from that very same file.

I personally think this should be relatively high priority, especially given it should be reasonably simple to implement.

All done! Please let me know if there's anything missing!


MAINT: sparse: write matrix/asmatrix wrappers without warning manipulations

Reference issue
Closes: gh-12449
What does this implement/fix?
warnings.catch_warnings is not threadsafe and has some other bugs (see gh-12449).
Replace using it by constructs that avoid the Numpy matrix warnings.
Additional information
The scipy.sparse __init__.py currently silences matrix warnings at import time. This could in principle now be removed, but it may be better for downstream to keep it, since e.g. multiplying dense matrices extracted from sparse would still raise warnings.
There are a few other places still in scipy that use catch_warnings, that could be cleaned up (however, less straightforward so should go to separate PR).

The function was added in 2019, and is not included in __all__ so I'd guess it's not widely used by 3rd parties.
On July 11, 2020 6:02:36 AM UTC, CJ Carey<EMAIL_ADDRESS>wrote:

@perimosocordiae approved this pull request.

-def bmat(*args, **kwargs):
I'm sure that someone, somewhere is doing from scipy.sparse.sputils import * or equivalent. But I wasn't able to find any obvious
instances with a cursory github search, so I think the risk is
acceptable.

The cognate issue is labelled as "defect," if this is a bug fix feel free to label with backport


Update docker instructions to listen on *

Finishing up #23 to catch the point you mentioned (about exposing the server port externally). This updates the instructions to make sure the server starts up listening on all interfaces, not just localhost.
With this you should be able to now just install docker and run the one command, and have a working staytus instance up and ready to go a minute later.

Thanks - merged


lyxal: Watch nonazodiak(?!.wixsite.com)

lyxal requests the watch of the watch_keyword nonazodiak(?!\.wixsite\.com). See the MS search here and the Stack Exchange search in text, in URLs, and in code.

nonazodiak(?!\.wixsite\.com) has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ


Have douitsu work on node v0.12

I know node 0.12 is still way out of date, however this is the first step to getting it up to node v8.

I've invited you to be a collaborator on this one too :)

Thanks 😄

Thanks @elliots :)
Are you still able to be involved in the Slack workspace: https://ninjasphere.slack.com


AudioManager.Current The type name Current does not exist in the current context

Adding the following to MauiProgram.cs reports "The type name Current does not exist in the type AudioManager"
builder.Services.AddSingleton(AudioManager.Current);

closing VS and reopening it resolved the issue. VS for Mac drives me insane at times


src folder in published package

I just noticed that the src folder is included in the npm package. From the code execution point of view, this folder is just cruft, right?
Is there any specific reason not to .npmignore this folder to save some KBs?

Haven't dealt with the packaging side, but I could see a potential use case for someone who's doing minimal amounts of transpiling to directly import the ES6 codebase files and use them as-is.

It's there for folks who want to read the source to better understand it. Removing is not really going to save any meaningful size.


image validator

Apply image validator to uploads. Class already exists, didn't add it in the running code yet.

https://github.com/flagrow/flarum-ext-image-upload/pull/25


add  somewhere in the documentation

I was wondering if we could have <base href="/"> added somewhere in the documentation or in the skelly index.html.
I struggled with this quite a while when I was building my application.  I only recently figured this out, and while it might seem basic to all the experts here, it wasn't obvious at all to me.

I know it isn't super easy to find but it is mentioned in the documentation here:

@bryanrsmith Please be sure to include this in the router docs you are writing. Thanks!


Fix orennayarbrdf.cpp: no longer try to normalizes zero vectors.

Calculate the norm of each vector first and do an early return if zero.
This avoids asserts in debug mode and divisions by null in release mode.

Thanks for your contribution @andreasdeclercq !

This avoids asserts in debug mode and divisions by null in release mode.

Can you please explain in which case you get divisions by null ? That would be great if you could provide a scene so that we can test.


Missing fltk.util.env

Bug Report
In line 25 of launch.py, fltk.util.env is imported but cannot be found.

Thank you for the :bug: report, the issue has been addressed and pulled into the main branch. Feel free to re-open the issue.


Automated cherry pick of #9813: fix(notify): loose phone number rules in updating receiver

Cherry pick of #9813 on release/3.5.
#9813: fix(notify): loose phone number rules in updating receiver

Codecov Report

Merging #9816 (e06dc3e) into release/3.5 (6a15e02) will increase coverage by 4.90%.
The diff coverage is 0.24%.

@@               Coverage Diff                @@
##           release/3.5    #9816       +/-   ##
================================================
+ Coverage         5.98%   10.88%    +4.90%
================================================
  Files              796      168      -628
  Lines           125693    17668   -108025
================================================
- Hits              7522     1924     -5598
+ Misses          117504    15577   -101927
+ Partials           667      167      -500

Flag
Coverage Δ

aFlag
10.88% <0.24%> (+4.90%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/apis/input.go
0.00% <ø> (ø)

pkg/cloudcommon/db/quotas/errors.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/quotas/handler.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/quotas/register.go
11.11% <0.00%> (-2.41%)
:arrow_down:

pkg/cloudcommon/db/quotas/usageworker.go
0.00% <0.00%> (ø)

pkg/compute/guestdrivers/aliyun.go
2.72% <0.00%> (-0.98%)
:arrow_down:

pkg/compute/guestdrivers/aws.go
2.27% <0.00%> (-0.67%)
:arrow_down:

pkg/compute/guestdrivers/azure.go
2.54% <0.00%> (-0.69%)
:arrow_down:

pkg/compute/guestdrivers/baremetals.go
1.06% <0.00%> (-0.02%)
:arrow_down:

pkg/compute/guestdrivers/base.go
0.00% <0.00%> (ø)

... and 577 more

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 c4f06b6...e06dc3e. Read the comment docs.

Codecov Report

Merging #9816 (e06dc3e) into release/3.5 (6a15e02) will increase coverage by 4.90%.
The diff coverage is 0.24%.

@@               Coverage Diff                @@
##           release/3.5    #9816       +/-   ##
================================================
+ Coverage         5.98%   10.88%    +4.90%
================================================
  Files              796      168      -628
  Lines           125693    17668   -108025
================================================
- Hits              7522     1924     -5598
+ Misses          117504    15577   -101927
+ Partials           667      167      -500

Flag
Coverage Δ

aFlag
10.88% <0.24%> (+4.90%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/apis/input.go
0.00% <ø> (ø)

pkg/cloudcommon/db/quotas/errors.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/quotas/handler.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/quotas/register.go
11.11% <0.00%> (-2.41%)
:arrow_down:

pkg/cloudcommon/db/quotas/usageworker.go
0.00% <0.00%> (ø)

pkg/compute/guestdrivers/aliyun.go
2.72% <0.00%> (-0.98%)
:arrow_down:

pkg/compute/guestdrivers/aws.go
2.27% <0.00%> (-0.67%)
:arrow_down:

pkg/compute/guestdrivers/azure.go
2.54% <0.00%> (-0.69%)
:arrow_down:

pkg/compute/guestdrivers/baremetals.go
1.06% <0.00%> (-0.02%)
:arrow_down:

pkg/compute/guestdrivers/base.go
0.00% <0.00%> (ø)

... and 577 more

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 c4f06b6...e06dc3e. Read the comment docs.


PNG caching of 16bit data flips endianess

Since PNG requires big endian input data, the byte order of the input data is usually flipped on write.  This is fine in most cases, but when the tile data is not discarted, it will have the bytes flipped.  This happens for caching MRFs with PNG as the caching format.

This was fix at some point in the GDAL trunk.


How can I provide multi select option for picklist type in vso-agent tasks?

One of our vso-agent tasks need an input of type "picklist" with multi select. How can I achieve this?

That feature doesn't exist yet.  The only way to achieve it today would be a group with multiple bool inputs
Adding to backlog


Crossing highway/railway - exclude railway=tram and railway=construction + construction=tram and railway=disused + disused=tram

Due to various weird geometry issues (railway=tram follow tram tracks and highway=* follow centerline of road) point where railway=tram line and highway=* line crosses is often NOT representing point where tram crosses road.
In JOSM for this reason trams are excluded from this rule.
See https://josm.openstreetmap.de/ticket/16889 for partial JOSM equivalent

See for an example https://www.openstreetmap.org/?mlat=50.07323&mlon=19.93585#map=19/50.07323/19.93585&layers=N

railway=tram line and highway=* line crosses is often NOT representing point where tram crosses road.

Okay, but the two features are still technically connected and if you're driving north through that intersection you'll still end up driving over the tracks. If that road was mapped bidirectionally it'd be even more accurate. Traffic lights and stop signs aren't mapped where they're physically located either.
Even putting all that aside, trams can still cross roads via bridges and tunnels. People would expect iD to flag these.

Okay, but the two features are still technically connected and if you're driving north through that intersection you'll still end up driving over the tracks. If that road was mapped bidirectionally it'd be even more accurate. Traffic lights and stop signs aren't mapped where they're physically located either.

Yeah I agree - the purpose of mapping the crossings isn't to make pretty maps of where the crossings are, but more to inform data consumers.  So that a cycling navigation app might flash up a message saying "watch out for tram tracks in 200m" or something.
I'm inclined to leave this validation as-is..

See https://www.openstreetmap.org/?mlat=50.06646&mlon=19.93905#map=19/50.06646/19.93905&layers=N - here there is no self-crossing - tram tracks are embedded in the road.

https://www.google.pl/maps/@50.0662939,19.9390377,3a,75y,15h,73.79t/data=!3m6!1e1!3m4!1sA865u1CQIVOHTxDQqdaZDQ!2e0!7i13312!8i6656
Or see for example https://www.openstreetmap.org/?mlat=50.07300&mlon=19.93584#map=19/50.07300/19.93584&layers=N
Here cycleway joins road (so it joins centerline mapped as highway=*). It crosses railway=tram. But it is not not crossing tram tracks!

https://www.google.pl/maps/@50.0728711,19.935888,3a,75y,6.6h,87.95t/data=!3m6!1e1!3m4!1sZDB9ac_5OW_U5AmZX8Pb3Q!2e0!7i13312!8i6656

There are multiple crossings of highway=* and railway=tram lines but no crossings should be mapped.

I fail to see how you would avoid crossing any tracks when turning at that intersection. I suggest mapping the two directions as separate ways if the accuracy matters, or feel free to ignore iD's warnings.

In JOSM for this reason trams are excluded from this rule.

I appreciate you drawing inspiration from existing work! But just because iD has validation warnings now doesn't mean we're going to do everything JOSM does.
@bhousel:

I'm inclined to leave this validation as-is..

Sounds good to me.

I appreciate you drawing inspiration from existing work! But just because iD has validation warnings now doesn't mean we're going to do everything JOSM does.

I intend it not in "iD must be JOSM equivalent" but "it is not merely my idea and at least one other person thought in the same way". Also, JOSM validator is quite mature and went through many iterations that removed various false positives so their rules are usually well tested.
I think that it is not useful to mention it explicitly every single time, but I can start doing it.

I intend it not in "iD must be JOSM equivalent" but "it is not merely my idea and at least one other person thought in the same way".

@matkoniecz That's fine! As long as you agree with the behavior too 🙂

@quincylvania wrote:

I suggest mapping the two directions as separate ways if the accuracy matters.

In OSM, a road is only split into two parallel ways if there is a physical separation between the two directions. (It's different for railway infrastructure where mapping one way per track is preferred) Therefore, splitting the road into parallel ways as you suggested would be mapping for validator.

In OSM, a road is only split into two parallel ways if there is a physical separation between the two directions.

I would argue that using two ways is an option anytime that a single way is insufficient to model the road as it exists in the real world. A physical barrier is one reason. Embedded tracks might be another. It's OSM though, so map them however you think is best!

Recently I toyed around with a pedestrian router for the blind and sometimes it went crazy detours. Digging into it, I found "railway=crossing" on footways crossing tram rails a major reason. As the tag is very rare in my local area (only 5 occurrences in all of the town), wondering how they came to be I learned, that iD suggests them. So I fired up iD, selected a tram line and clicked "connect" in the validator as long as there was nothing left to click. In the end I had created 27 railway crossings and level crossings on only 1 km of tram line! Further I got a "Your edits look good" green box after "fixing" three more warnings of the same kind in the validator.
I think that is completely overblown:

Tram rails embedded into a street do not anywhere look like the pictures for "railway=crossing" in the OSM wiki. I am in no way certain, that the tag is actually applicable. One may counter, that the router then should handle railway crossings differently in case the railway is a tram, but beware: the router has no way to know, whether the rails are embedded into the street, if the crossing is protected by a traffic signal on the embedding street, or if the crossing is actually something that looks like shown on the wiki.
Several of the crossings do in fact not exist at all, e.g. like in the second picture above, or where a footway or a street joins in. The workaround suggested, to map lanes of a street separately though goes against the good-practice principle of one feature on ground to have one entity in OSM, where tram and cars share the same space, a continuous paved carriageway for a bidirectional street that happens to have tram rails embedded.

@hungerburg Sorry this is causing issues for you! Look at it this way… these are the options I saw for what iD should do about tram and road/path crossings:

Don't flag them. This leaves the layering and topology ambiguous.
When connecting, don't tag the node. Routers wouldn't know there's anything special about these nodes (which seems like a big problem for blind pedestrian routers).
When connecting, tag the node as a level crossing.

So while I continue to think the last one is the least bad, I agree that tramway crossings are rather different than full railway level crossings. As such, a fourth option comes to mind:

When connecting, tag the node specifically as a tram crossing.

Turns out there are already tags for this with a few thousands uses, railway=tram_level_crossing and railway=tram_crossing. Seems established enough to use in iD. I wish we'd known about these before!

@quincylvania Great something came out of this. The fourth option clearly rules. Much better than option 3. It makes explicit what the router implicitly assumes in option 2. This is just a guess though, from reading the text form itinerary. I mapped two of those for control. I do not expect that the router knows about the new tags and will do as in option 2.
That leaves the cases, where there is in fact no crossing at all, or perhaps depending on whether one does a right turn or a left turn…


ROX-17159: ExternalNetworkSourcesTest fix double deletion

Description
This is a follow-up from #6570 where we introduced a failure in the tests if the external entity isn't deleted, but there was one case where the entity was deleted both in the tests and the cleanup. Causing the second deletion to fail.
Checklist

[x] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

Testing Performed

[ ] CI

Looks like all ExternalNetworkSourcesTest ran (and passed) now.
ExternalNetworkSourcesTest > Verify flow re-maps to larger subnet when smaller subnet deleted PASSED


Update test requirements

Let's use released version instead of repositories, whenever possible

Coverage remained the same at 91.07% when pulling 641c9984adce7cc31dc762a3341b7ba7762cd975 on yakky:feature/update_test_requirements into a95f0fc33efef5eab5d700ed6961b153b284d8bf on divio:support/3.1.x.

Coverage remained the same at 91.07% when pulling 641c9984adce7cc31dc762a3341b7ba7762cd975 on yakky:feature/update_test_requirements into a95f0fc33efef5eab5d700ed6961b153b284d8bf on divio:support/3.1.x.


Introduces UnsupportedPropertiesContext, Utill and use it in Symbolizer Editors

Description
This introduces the UnsupportedPropertiesContext, UnsupportedPropertiesUtil and makes use of them in the Symbolizer Editors.

Supported Editors:

[ ] LineEditor
[x] FillEditor
[ ] MarkEditor
[ ] IconEditor
[ ] TextEditor
[ ] RasterEditor

Pull request type
Please check the type of change your PR introduces:

[ ] Bugfix
[x] Feature
[ ] Dependency updates
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe)
[ ] I am unsure (we'll look into it together)

Do you introduce a breaking change?

[ ] Yes
[x] No
[ ] I am unsure (no worries, we'll find out)

Checklist

[x] I understand and agree that the changes in this PR will be licensed under the BSD 2-Clause License
[x] I have followed the guidelines for contributing
[x] The proposed change fits to the content of the code of conduct
[] I have added or updated tests and documentation, and the test suite passes (run npm test locally)
[ ] I'm lost; why do I have to check so many boxes? Please help!

I generally like the idea. I'm just wondering if the user experience would be improved by removing the input field, if it is not supported, instead of showing the info text.

Also, should the context provide more than one parser?

I generally like the idea. I'm just wondering if the user experience would be improved by removing the input field, if it is not supported, instead of showing the info text.

This could be an option. I thought about disabled status too but with the current concept i just can add properties to the antd Form.Item as the unsuportedProperties. Not rendering it at all should work though.

Also, should the context provide more than one parser?
The context does not provide a parser at all but an unsupportedProperties object. I wouldn't change this.

Also, should the context provide more than one parser?
The context does not provide a parser at all but an unsupportedProperties object. I wouldn't change this.

My bad, I meant if the context should provide more than one unsupportedProperties object. If e.g. SLD and Openlayers parsers are used, we have two different unsupportedProperties objects. With the current approach, users would have to merge the two objects into a single one, in order to provide infos about unsupported properties of both parsers. This could be simplified by providing an array of unsupportedProperties objects.

Also, should the context provide more than one parser?
The context does not provide a parser at all but an unsupportedProperties object. I wouldn't change this.

My bad, I meant if the context should provide more than one unsupportedProperties object. If e.g. SLD and Openlayers parsers are used, we have two different unsupportedProperties objects. With the current approach, users would have to merge the two objects into a single one, in order to provide infos about unsupported properties of both parsers. This could be simplified by providing an array of unsupportedProperties objects.

The merge of two unsupportedProperties might include conflicts which can't be solved logically without knowing the context of use. So I'll prefer to leave this to the user.


partition-data.csv get generated automatically or how we define those

hi i have following queries on below
https://github.com/microsoft/CDM/tree/master/samples/6-create-net-new-entities
Does partition-data.csv get generated automatically or their are any procedure for their creation
how can we mouth Manifest , Partition data to the ADLS gen 2 ?

Hello,
this sample currently doesn't generate the CSV file.
You can have a look at the 2-create-manifest sample since it includes a small code snipped to create a CSV header containing the attribute names and save that to your local disk.
In short all you need to do is put the code below after this line.
// Make a fake file with nothing but header for columns
string header = "";
foreach(CdmTypeAttributeDefinition att in entDef.Attributes)
{
    if (header != "")
        header += ",";
    header += att.Name;
}

await cdmCorpus.Storage.FetchAdapter("adls").WriteAsync("/path/data-partition.csv", header);

Just remember that you also need to uncomment the part of the code where you mount the "adls" adapter.

Thanks


High res textures as height for bump node cause massive freeze

Description
When having a material with a bump node, which takes a high resolution texture as input (in my tests they were 8k textures) and exporting as gltf 2.0, the (or at least my) PC slowly hangs up and almost crashes. I thought it might be my CPU. which couldn't keep up with the exporter, so i tried to let it sit for some time, with no results (at one point i have waited 90 minutes), but it might also be that the RAM isn't sufficient (when looking at blender in the task manager, its RAM use raises from ~500mb to almost 5gb, where it stops and freezes the whole computer, and even closes other programs).
This problem can be prevented by disabling "Material" under "Geometry" in the export setting, but it would still be great if this problem didnt exist in the first place.
How to reproduce

Create any type of 3D mesh object, and add a material
Create a bump node, and connect it to the normal input of the principled node
Create a new texture in the image panel with a high resolution (i tested with 8192x)
create an image texture node, select the newly created image, and connect it with the 'height' slot of the bump node
export the scene as gltf (with materials)
CAUTION: This might lead your PC to freeze for half an hour or longer!

Expected behavior
The Exporter creates the primitives of the mesh with the material (see console output) and then freezes. The RAM usage of blender raises tremendously, until the whole computer freezes.
Version

OS: Windows 10, Version 1903
Blender Version 2.80 / 2.81

My CPU is an Intel Ceon E3-1231 v3, and i have 8GB RAM, if those stats matter.

Duplicate of #203
Please follow submission template and provide an example .blend file, it will save a few minutes for developer that will investigate it.
Thanks!


Fatal error on TFLite delegate load

When trying to load the TFLite delagate:
import tflite_runtime.interpreter as tflite

armnn_delegate = tflite.load_delegate(
    library="/home/aurelien/Projects/PreBuilts-Binaries/ArmNN-linux-aarch64/libarmnnDelegate.so",
    options={"backends": "CpuAcc,GpuAcc,CpuRef", "logging-severity": "trace"}
)

But I get this error:
Info: ArmNN v30.0.0
(8240) PVR:(Fatal): Debug assertion failed! (uiNumValidDevices > 0) [ device.c:521 ]
Aborted

I'm using a Beaglebone AI-64:
$ lscpu
Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          2
On-line CPU(s) list:             0,1
Thread(s) per core:              1
Core(s) per socket:              2
Socket(s):                       1
Vendor ID:                       ARM
Model:                           0
Model name:                      Cortex-A72
Stepping:                        r1p0
BogoMIPS:                        400.00
L1d cache:                       64 KiB
L1i cache:                       96 KiB
L2 cache:                        1 MiB
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

Thanks!

My bad, I installed the incorrect OS for my Beaglebone. Oops, now it runs fine!


(do not merge, updating) (BKR-366) merge-up install_from_git changes from deployer and puppet

This change merges changes to install_from_git that were overloaded into
puppet and other repos' acceptance libraries.
We also split the cloning portion of install_from_git into its own
method, added options that are passed through to on() and moved a method
to beaker's acceptance library that needs to be shared across tests
(install_packages_on).
This addition of an acceptance library for beaker may require changes to
the jenkins CI configuration, to add the library to the test-runner's
load-path.
The merge-up also brought in helpers for install_from_git,
build_git_url() and lookup_in_env().

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1040/
Test FAILed.

Errors during yard doc generation:
[warn]: @param tag has unknown parameter name: git_fork;
    in file `lib/beaker/dsl/install_utils/foss_utils.rb' near line 63
[warn]: @param tag has unknown parameter name: git_server;
    in file `lib/beaker/dsl/install_utils/foss_utils.rb' near line 63
[warn]: @param tag has unknown parameter name: git_fork;
    in file `lib/beaker/dsl/install_utils/foss_utils.rb' near line 63
[warn]: @param tag has unknown parameter name: git_server;
    in file `lib/beaker/dsl/install_utils/foss_utils.rb' near line 63
Files:         112
Modules:        69 (   39 undocumented)
Classes:        61 (   30 undocumented)
Constants:      85 (   63 undocumented)
Methods:       790 (  183 undocumented)
 68.66% documented

@anodelman oops.  updated, docs gen works on my end.

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1045/
Test FAILed.

the load_path needs updating for this PR (it moved an acceptance helper to lib/beaker/acceptance/blah)

retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1072/
Test FAILed.

retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1091/
Test FAILed.

@er0ck it looks like it made it past the Beaker acceptance and now is failing on the Puppet acceptance suite that it runs to make sure there aren't regressions (I think that's what that means, @anodelman would know for sure).

@justinstoller can you point out the log for that?  puppet acceptance uses install_packages_on which i moved to beaker's acceptance lib in this PR (which puppet has in its acceptance lib), because it's used in multiple pre-suites and tests.

Here's the chunk of interest.
#<LoadError: cannot load such file -- beaker/acceptance/install_utils>
/var/lib/jenkins/workspace/qe_beaker_intn-sys_beaker-acceptance-puppet-vpool-puppet-git/agent/centos7/master/centos7/acceptance/pre_suite/puppet_git/install.rb:2
/var/lib/jenkins/workspace/qe_beaker_intn-sys_beaker-acceptance-puppet-vpool-puppet-git/agent/centos7/master/centos7/acceptance/pre_suite/puppet_git/install.rb:2
/var/lib/jenkins/workspace/qe_beaker_intn-sys_beaker-acceptance-puppet-vpool-puppet-git/agent/centos7/master/centos7/lib/beaker/test_case.rb:128
/var/lib/jenkins/workspace/qe_beaker_intn-sys_beaker-acceptance-puppet-vpool-puppet-git/agent/centos7/master/centos7/lib/beaker/test_case.rb:128

looks like load_path issues to me

Ahhh... Wow, there's a lotta testing.
So I followed the link that Jenkins provided above. Previously the [Phase] - Acceptance Tests - Base had been failing and I updated the Beaker Acceptance Base (vpool) job with the new load path. After updating that all of the [Phase] - Acceptance Tests - Base succeeded and then failed on [Phase] - Acceptance Tests - Puppet. It seems that I erroneously assumed those were where we used the Puppet acceptance suite to test that there are no regressions (which I thought we still did). Apparently that's not the case, I've updated all the jobs in [Phase] - Acceptance Tests - Base and [Phase] - Acceptance Tests - Puppet with the updated load path....

retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1092/
Test FAILed.

i don't get it.  acceptance looks green to me in that 1092 link

Looks like the results aged off the server, will have to re-run.

retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1110/
Test FAILed.

again.  looks like it's passing/grey to me?  but i'm lost in this sea of jenkinseses

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1151/
Test FAILed.

@justinstoller this is still failing due to load_path issues, it appears.

@anodelman so I tried to help out here by updating the job configurations and got bit by the fact that there's I don't understand how the acceptance tests are grouped or laid out. I've just gone and double checked that all of the [Phase] - Acceptance Tests - Puppet jobs are calling beaker with --load-path lib. Why that isn't working on one of them, I don't know.  Please, see @er0ck's comment above.

retest this please

updated load path.

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1152/
Test FAILed.

getting somewhere... only failing on windows.  looking into it

@anodelman 'sup with this thing?  you get anywhere on this?

retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1230/
Test FAILed.

retest this please

retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1267/
Test FAILed.

retest this please

retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1275/
Test FAILed.

retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1284/
Test FAILed.

uh... looks all green to me?

@puppetlabs-jenkins retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1292/
Test FAILed.

Failure unrelated to patch.

retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1302/
Test PASSed.

aww yiss @kevpl


feat: disable Netlify caching for schemas serving + rely in GH caching

Description
In a previous PR, I enabled Netlify cache for calls made to our /schema-store and /definitions paths.
It worked ok, the problem is that we can't track metrics of cached results since requests are never reaching the edge-function but rather Netlify's cache layer. In a normal env, this will be exactly the desired behaviour, since it is so performant. However, we need to track requests with a 304 from GH as well, so we rollback the previous changes and now rely directly in GH cache. That will make the request just a bit slower but we will have adoption metrics, which is a WIN.
Metrics will now have a new field called cached that will indicate if a 304 was returned by GH.
Related issue(s)
https://github.com/asyncapi/website/issues/780#issuecomment-1125358517
cc @derberg

/rtm