Somehow I soft-bricked the coordinator?

So last night I was playing around setting up zigbee devices, and after turning off (from the physical switch) a group of lights everything stopped working. I've tried restarting zigbee2mqtt, resetting the coordinator (from the button on the device), and even tested it on a different machine but I get the same results. This is what I get when booting zigbee2mqtt with the debug flag:
  zigbee2mqtt:info 5/21/2019, 7:07:45 AM Logging to directory: '/app/data/log/2019-05-21.07-07-45'                                                                                [35/73]
  zigbee2mqtt:debug 5/21/2019, 7:07:45 AM Removing old log directory '/app/data/log/2019-04-10.22-04-11'
  serialport/bindings loading LinuxBinding +0ms
  zigbee2mqtt:debug 5/21/2019, 7:07:45 AM Using zigbee-shepherd with settings: '{"net":{"panId":6754,"extPanId":[221,221,221,221,221,221,221,221],"channelList":[11],"precfgkey":"HIDDEN"},"dbPath":"/app/data/database.db","coordBackup
Path":"/app/data/coordinator_backup.json","sp":{"baudRate":115200,"rtscts":true}}'
  zigbee2mqtt:debug 5/21/2019, 7:07:45 AM Loaded state from file /app/data/state.json
  zigbee2mqtt:debug 5/21/2019, 7:07:45 AM Saving state to file /app/data/state.json
  zigbee2mqtt:info 5/21/2019, 7:07:45 AM Starting zigbee2mqtt version 1.4.0 (commit #unknown)
  zigbee2mqtt:info 5/21/2019, 7:07:45 AM Starting zigbee-shepherd
  zigbee-shepherd:init zigbee-shepherd booting... +0ms
  cc-znp Initialize, opening serial port +0ms
  serialport/stream opening path: /dev/ttyACM0 +0ms
  serialport/binding-abstract open +0ms
  serialport/stream _read queueing _read for after open +3ms
  serialport/bindings/poller Creating poller +0ms
  serialport/stream opened path: /dev/ttyACM0 +151ms
  serialport/stream _write 1 bytes of data +1ms
  serialport/binding-abstract write 1 bytes +156ms
  serialport/stream _read reading +2ms
  serialport/binding-abstract read +2ms
  serialport/bindings/unixWrite Starting write 1 bytes offset 0 bytesToWrite 1 +0ms
  serialport/bindings/unixRead Starting read +0ms
  serialport/bindings/unixWrite write returned null 1 +7ms
  serialport/bindings/unixWrite wrote 1 bytes +0ms
  serialport/bindings/unixWrite Finished writing 1 bytes +0ms
  serialport/stream binding.write write finished +10ms
  serialport/bindings/unixRead waiting for readable because of code: EAGAIN +8ms
  serialport/bindings/poller Polling for "readable" +17ms
  cc-znp The serialport /dev/ttyACM0 is opened. +1s
  zigbee-shepherd:request REQ --> SYS:version +0ms
  cc-znp:SREQ --> SYS:version, {} +0ms
  serialport/stream _write 5 bytes of data +1s
  serialport/binding-abstract write 5 bytes +1s
  serialport/bindings/unixWrite Starting write 5 bytes offset 0 bytesToWrite 5 +1s
  serialport/bindings/unixWrite write returned null 5 +1ms
  serialport/bindings/unixWrite wrote 5 bytes +0ms
  serialport/bindings/unixWrite Finished writing 5 bytes +0ms
  serialport/stream binding.write write finished +2ms
  cc-znp:SRSP <-- SYS:version, __timeout__ +0ms
  zigbee-shepherd:request RSP <-- SYS:version +3s
  zigbee-shepherd:request REQ --> SYS:osalNvRead +7ms
  cc-znp:SREQ --> SYS:osalNvRead, { id: 3840, offset: 0, len: 1, value: [ 85 ] } +3s
  serialport/stream _write 8 bytes of data +3s
  serialport/binding-abstract write 8 bytes +3s
  serialport/bindings/unixWrite Starting write 8 bytes offset 0 bytesToWrite 8 +3s
  serialport/bindings/unixWrite write returned null 8 +3ms
  serialport/bindings/unixWrite wrote 8 bytes +0ms
  serialport/bindings/unixWrite Finished writing 8 bytes +1ms
  serialport/stream binding.write write finished +7ms
  cc-znp:SRSP <-- SYS:osalNvRead, __timeout__ +3s
  zigbee-shepherd:request RSP <-- SYS:osalNvRead +3s
  zigbee-shepherd:init Coordinator initialize had an error: Error: request timeout
    at CcZnp.<anonymous> (/app/node_modules/cc-znp/lib/ccznp.js:269:22)
    at Object.onceWrapper (events.js:273:13)
    at CcZnp.emit (events.js:182:13)
    at Timeout.<anonymous> (/app/node_modules/cc-znp/lib/ccznp.js:248:18)
    at ontimeout (timers.js:436:11)
    at tryOnTimeout (timers.js:300:5)
    at listOnTimeout (timers.js:263:5)
    at Timer.processTimers (timers.js:223:10) +0ms
  zigbee2mqtt:info 5/21/2019, 7:07:53 AM Error while starting zigbee-shepherd, attempting to fix... (takes 60 seconds) (Error: request timeout)

The only thing I haven't tried is reflashing the firmware (I bought the CC2531 coordinator ready flashed with a 201902?? firmware), which I will try this evening. I assume something has become messed up on the memory of the device. Is this not what the 'Reset' button is supposed to fix though?
As a side note, is there any way to set my lightbulbs as end devices rather than routers?

It seems that indeed something has been messed up in the memory, reflashing should fix it.
AFAIK in Zigbee it's not possible to change devices from routers to end devices.

Yup reflashing fixed it :+1:


import terms from HP, NCBITaxon, SNOMED

There are imported terms in the project ontology files that are not in the EuPath release.
I propose importing the following terms from HP:
shock 		HP_0031273
‘eye pain’ 	HP_0200026
‘ear pain’ 	HP_0030766
fever 		HP_0001945
as subclasses of ‘phenotypic abnormality’ HP_0000118
(shock and ‘eye pain’ are already in EUPATH but from non-OBO ontologies)
and the following terms from NCBITaxon:
Dengue 		NCBITaxon_12637
Chikungunya 	NCBITaxon_37124
as subclass of Viruses NCBITaxon_10239
and
Typhus 		NCBITaxon_114292
as subclass of Bacteria NCBITaxon_2
Finally, ‘acute pulmonary edema’ from SNOMED is in web_display.owl but not in the release. EuPath does have ‘pulmonary edema’, which could serve as superclass for ‘acute pulmonary edema’. However, this term is not in any OBO ontology, and has no definition in the non-OBO ontologies that do have this term. So do we carry over the SNOMED term or create a new term for EuPath?

Agreement was reached on including all above terms except 'acute pulmonary edema'; after discussion w/pulmonologist, we decided 'pulmonary edema' would suffice.


Standard repo tidying.

@hoatle - I think adding some small docs and standard OSS repo items would be good, such as a pull request template, contributor's guidelines, etc.
Let me know your thoughts and if you have something you want to do for this in mind, otherwise I can slowly get it done.

@hjc yeah, that's good to me. I guess we can follow the guides here to update for our repo: https://opensource.guide/

Sweet! I'll check this out in the next few days.


MONDO:0004964 & MONDO:0019476 Peripheral T-cell lymphoma [Merge]

Mondo term (ID and Label)
MONDO:0004964 Peripheral T-cell lymphoma, not otherwise specified
Reason for deprecation
UMLS puts these on same CUI
NCIT has other sub-types grouped under this term (intent seems to be a broader concept without specific subtype markers/morphology)
Term to be merged with
MONDO:0019476 Peripheral T-cell lymphoma
Your nano-attribution (ORCID)
If you don't have an ORCID, you can sign up for one here

@kanems is MONDO:0019476 the correct Mondo ID? The label for this is 'primary cutaneous peripheral T-cell lymphoma not otherwise specified' not 'Peripheral T-cell lymphoma'. Also, what CUI do you see where these are the same?

Hi @twhetzel yes, that's the right Mondo ID, I copied the SNOMED CT preferred name from our database by error, whoops!
The merge suggestion is MONDO:0004964 (peripheral T-cell lymphoma, not otherwise specified) & MONDO:0019476 (primary cutaneous peripheral T-cell lymphoma not otherwise specified)
Here is a screenshot from UMLS's Metathesaurus browser that shows their concept mappings for C0079774 (the CUI is highlighted in the URL at the top, x-refs I often see in Mondo and we treat as authoritative are also highlighted)

(2024-03-28 Mondo expert call):
We might need to talk to a Tcell expert

We have discussed this further and at this time we believe MONDO:0004964 (peripheral T-cell lymphoma, not otherwise specified) & MONDO:0019476 (primary cutaneous peripheral T-cell lymphoma not otherwise specified) to represent two different T-cell populations.

Thanks for this decision, MedGen will keep these separate as well.


Readme out of date, error: launchChrome is not a function

Trying to run the following code:
const launchChrome = require('@serverless-chrome/lambda');
export const hello = (event, context, callback) => {
  launchChrome({}).then(chrome => {
    console.log(chrome);
    callback(null, {
      status: 'it worked'
    })
  }).catch(callback);
};

via serverless invoke local -f first I receive the error: launchChrome is not a function. Is the readme out of date with the API?

Hi @zachschultz — Hm.. What do you get when you console.log(launchChrome) ? Does the following work?
const launchChrome = require('@serverless-chrome/lambda').default;

export const hello = (event, context, callback) => {
  launchChrome().then(chrome => {
    console.log(chrome);
    callback(null, {
      status: 'it worked'
    })
  }).catch(callback);
};


chore: fix broken tests

Related Issues/PRs

#xxx
What changes are proposed in this pull request?
Briefly describe the changes included in this Pull Request.
How is this patch tested?

[ ] I have written tests (not required for typo or doc fix) and confirmed the proposed feature/bug-fix/change works.

Does this PR change any dependencies?

[ ] No. You can skip this section.
[ ] Yes. Make sure the dependencies are resolved correctly, and list changes here.

Does this PR add a new feature? If so, have you added samples on website?

[ ] No. You can skip this section.
[ ] Yes. Make sure you have added samples following below steps.

Find the corresponding markdown file for your new feature in website/docs/documentation folder.
Make sure you choose the correct class estimators/transformers and namespace.
Follow the pattern in markdown file and add another section for your new API, including pyspark, scala (and .NET potentially) samples.
Make sure the DocTable points to correct API link.
Navigate to website folder, and run yarn run start to make sure the website renders correctly.
Don't forget to add <!--pytest-codeblocks:cont--> before each python code blocks to enable auto-tests for python samples.
Make sure the WebsiteSamplesTests job pass in the pipeline.

/azp run

Codecov Report

Merging #1981 (2ffe96c) into master (fc5d699) will decrease coverage by 38.60%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master    #1981       +/-   ##
===========================================
- Coverage   87.02%   48.42%   -38.60%
===========================================
  Files         305      305
  Lines       15993    15993
  Branches      839      839
===========================================
- Hits        13918     7745     -6173
- Misses       2075     8248     +6173

see 201 files with indirect coverage changes


[cli] Bad parameter number to _PlistParser

_PlistParser.init() constructor in plistlib module requires one parameter,
but we passed two.

I'm not sure how this worked earlier. _PlistParser class is not included in the official documentations. And since it starts with _, I assume the intention of the library implementation was not to use this symbol externally. In the source code of plistlib it shows that this class requires 1 parameter in its constructor, but we pass 2. I don't know if it was different in the earlier versions of this lib. But CodeChecker parse fails to parse plist files without this change.

I also observe the issue. I believe it's caused by Python 3.9 changes in plistlib(commit).
Here's a snippet of CodeChecker parse --verbose debug ./reports
[DEBUG][2020-12-07 10:47:30] {system} [98538] <117234218923840> - parse.py:540 parse_with_plt_formatter() - Parsing input file '/REDACTED/curl/reports/socks_sspi.c_clangsa_469d2f144b53a6189ed674e620de8f03.plist'
[DEBUG][2020-12-07 10:47:30] {report} [98538] <117234218923840> - plist_parser.py:148 parse_plist_file() - Parsing plist: /REDACTED/curl/reports/socks_sspi.c_clangsa_469d2f144b53a6189ed674e620de8f03.plist
[WARNING][2020-12-07 10:47:30] {report} [98538] <117234218923840> - plist_parser.py:112 parse_plist() - Invalid plist file
[WARNING][2020-12-07 10:47:30] {report} [98538] <117234218923840> - plist_parser.py:113 parse_plist() - __init__() takes 2 positional arguments but 3 were given
[ERROR][2020-12-07 10:47:30] {report} [98538] <117234218923840> - plist_parser.py:159 parse_plist_file() - Failed to parse plist /REDACTED/curl/reports/socks_sspi.c_clangsa_469d2f144b53a6189ed674e620de8f03.plist

$ python --version
Python 3.9.0
$ pip list
Package                Version
---------------------- -------
alembic                1.4.2
codechecker-api        6.36.0
codechecker-api-shared 6.36.0
lxml                   4.5.0
Mako                   1.1.3
MarkupSafe             1.1.1
pip                    20.2.3
portalocker            1.7.0
psutil                 5.7.0
python-dateutil        2.8.1
python-editor          1.0.4
PyYAML                 5.3.1
setuptools             49.2.1
six                    1.15.0
SQLAlchemy             1.3.16
thrift                 0.13.0

thanks @hexcat, in this case @bruntib we will need some solution which will work with the newer 3.9 and the older 3.6-3.9 interpreter versions too


Update Contributors.md

please

contribute to #additional-material directory. I will approve any of it.

Thanks for pull this repository.
But you can't participation in hacktoberfest if just update contributors.md files.

Please re-upload and upload ur contribute files in #additional-material directory


[CH] Optimize get_json_object nested function calls

Description
In our online sqls, have some nested get_json_object function calls, like get_json_object(get_json_object(d, '$.a'), '$.b'), and some of them can be optimized to get_json_object(d, '$.a.b'), which can improve the performance

some nested get_json_object call case can not optimized:  select get_json_object(get_json_object('{"a":"{\\\"x\\\":5}"}', '$.a'), '$.x') can not be converted to select get_json_object('{"a":"{\\\"x\\\":5}"}', '$.a.x');

Yes, it is a corner case. In most cases, it can be converted. @PHILO-HE

@KevinyhZou, I feel we can merge the patch for both CH backend and velox backend if it's in good shape. If you are afraid of any similar issue, it's ok to keep a config for users to control the use of this optimization. Thanks!


Handle MPANs with missing leading zeros

MPAN function accepts int and cast them to str, however, some MPANs contain leading zeros, as such, these MPANs break the checksum and length checks.
e.g. str(int("00123412341234")) becomes "123412341234". It is a trivial fix to prepend the zeros and run the checksum. If it passes, we can be pretty sure this is the correct fix for the MPAN.

I feel terrible.  This is the first issue created for this library from someone else at the company and I have to reject it.  I'm so sorry.
The problem I have with this is that MPANs are not integers.  While they're often composed entirely of numbers, this (a) isn't always the case (sometimes there's letters!), and (b) the fact that they're mostly numbers doesn't make the MPAN an integer: it's simply a series of numeric fields glued together with no separators.  For this reason, treating it like an integer isn't something we should be encouraging.
I also have some deep objections to the idea that a library designed to parse a string would alter that string as part of the parsing process.  That's a big no-no in my book.
So in summary, my advice is that if you're currently casting an MPAN as an int in your own code, you should definitely stop doing that 'cause LLFCs are going to cause you pain one day, and if you've got an int that you want to treat like an MPAN and are comfortable with the idea of just adding zeroes to the left, then just use some string formatting on it before you pass it in:
my_int_mpan_as_a_string = str(my_int_mpan).rjust(21, "0")
MPAN(my_int_mpan_as_a_string)


Rails/DynamicFindBy issue with Gem::Specification.find_by_name

The analyzer should not complain about Gem::Specification.find_by_name as this is not an ActiveRecord model and so using find_by_name is correct:
Offenses:

spec/features/admin/orders/adding_line_items_spec.rb:5:11: C: Rails/DynamicFindBy: Use find_by instead of dynamic find_by_name.
gem_dir = Gem::Specification.find_by_name("solidus_backend").gem_dir
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

1 file inspected, 1 offense detected

This is an old issue from the original Rubocop repo: https://github.com/rubocop-hq/rubocop/issues/4967
RuboCop version
Include the output of rubocop -V or bundle exec rubocop -V if using Bundler. Here's an example:
$ [bundle exec] rubocop -V
0.68.1 (using Parser <IP_ADDRESS>, running on ruby 2.5.0 x86_64-darwin17)

This is also an issue when using ActiveRecord::Querying#find_by_sql


Destroy dynamic thread pool in Server

What problem does this PR solve?
Issue Number: close #6336
Problem Summary:
What is changed and how it works?
related https://github.com/pingcap/tiflash/pull/6340 https://github.com/pingcap/tiflash/pull/6367
Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/cc @ywqzzy @windtalker

/merge


N15: Add learning materials section w/ bevy snake tutorial

I couldn't figure out the stuff in the contributing document about reserving sections, but hopefully this is close enough... lmk if there's any changes needed.
Part of #320 ("Newsletter 15")

Thanks for the PR!


Module 3 exercises [Bashara  Ahmed Abubakari]

Land Condition Map - Exercise 1.pdf
The Market Suiability Map - Exercise 2.pdf

Please "drag & drop" exercise 1 pdf file below.

Please "drag & drop" exercise 2 pdf file below.

Please UPDATE THE TITLE of this "Issue" in the title bar above with your name.

If you haven't done so, please go back to Module 3 and make sure to take
the post-training survey. Participating in surveys is required for receiving
the "GALUP Certificate" by the University of Florida.

Well done, Bashara. You clearly grasped the material outlined in Module 3 and successfully applied it to these exercises. Thank you for your participation! Please be sure to fill out the post-Module survey before you begin the next Module.


Documentation  suggestions (pain points)

@kwilcox asked me to let him know where documentation would be helpful.  If it's OK, I'd like to track it here.
First up, Installation.  For instance, I did:

conda create -n pyocean pip
source activate pyocean
git clone https://github.com/pyoceans/pocean-core
cd pocean-core
conda install --file requirements.txt -c conda-forge
pip install -e ~/Desktop/code/pocean-core

dimension names are fixed, which is OK because CF documentation states: "This convention does not standardize any variable or dimension names".  Must be x,y,z,t. But maybe need to adjust the incoming data.

Some attributes seem to be defined by these routines.  Are they overwriting the ones I define?

@eldobbins Good call on the axes naming, this needs to be documented:
There is actually a way around the fixed dimension names. You can pass an axes mapping to many of the pocean functions if you don't want to use the predefined x, y, z, t, obs, profile, trajectory.
For example:
axes = {
    't': 'time',
    'x': 'lon',
    'y': 'lat',
    'sample': 'obs',
}

ncd = IncompleteMultidimensionalTrajectory.from_dataframe(df, axes=axes, output=somefile)

Will make a file with the dimensions/variables named time, lon, lat and obs. It is assumed each axes in the mapping is a column in df. Code that overwrite the defaul axes with the provided mapping: https://github.com/pyoceans/pocean-core/blob/master/pocean/utils.py#L38.


Incomplete  rule causes following rules not to be executed

Describe the bug
Hey, I just ran into an issue where an incomplete <exclude> rule (a copy/paste leftover) caused following rules in the phpcs.xml not to be executed.
Code sample
I don't have a simple code sample at this time.
Custom ruleset
See https://github.com/chillerlan/php-qrcode/blob/da5bdb82c8755f54de112b271b402aaa8df53269/phpcs.xml.dist#L38
<?xml version="1.0"?>
<ruleset name="My Custom Standard">
 	<rule ref="Generic">
		<!-- exclude some rules -->
		<exclude name="Generic.PHP.UpperCaseConstant" />
		<exclude name="Generic.WhiteSpace.DisallowTabIndent" />

		<!-- here's the copy/paste leftover -->
		<exclude name="Generic." />
	</rule>

	<!-- some more rules, rulesets, etc. -->
	<rule ref="PEAR">
		<exclude name="PEAR.Classes" />
	</rule>

</ruleset>

To reproduce
Steps to reproduce the behaviour:

Clone chillerlan/php-qrcode, checkout at tag 5.0.2 (commit da5bdb82c8755f54de112b271b402aaa8df53269) and run composer install
Run phpcs
There will be ca 6 errors reported
Now remove the aforementioned superfluous line
Run phpcs again
The reported errors are now a couple hundred

Expected behaviour
An incomplete or invalid rule should be ignored and error detection should resume normally (maybe emitting a message hinting at the invalid rule), meaning for the above example that the number of reported errors should always be a couple hundred.
Versions (please complete the following information)

Operating System
Windows 10

PHP version
8.3

PHP_CodeSniffer version
3.10.2

Standard
custom (see phpcs.xml.dist)

Install type
Composer

Additional context
The result with the above custom standard will likely be similar in other projects (may save the hassle to clone that specific project).
In the latest version of my library I have completely changed the phpcs.xml to include select rules, rather than using exclude blocks.
Please confirm

[x] I have searched the issue list and am not opening a duplicate issue.
[x] I have read the Contribution Guidelines and this is not a support question.
[x] I confirm that this bug is a bug in PHP_CodeSniffer and not in one of the external standards. (no external standards were used)
[x] I have verified the issue still exists in the master branch of PHP_CodeSniffer. (the latest version was used, main branch is 1 commit ahead as of now)

@codemasher Thanks for reporting this, but in my opinion this is not a bug and everything is working as expected.
You can exclude individual error codes, sniffs, categories and even complete standards. In this case, a complete standard is being excluded. The stray . at the end should be tolerated by PHPCS and should not be a reason for PHPCS to change its behaviour.
Excluding Generic from Generic is of course not that useful, as in that case the whole block could be removed, but that's not a concern for the engine itself.
Also see the Annotated ruleset documentation.

<!--
    You can even exclude a whole standard. This example includes
    all sniffs from the Squiz standard, but excludes any that come
    from the Generic standard.
 -->
 <rule ref="Squiz">
  <exclude name="Generic"/>
 </rule>

In the latest version of my library I have completely changed the phpcs.xml to include select rules, rather than using exclude blocks.

That's up to you, but it will increase your maintenance burden if you want to use predefined standards as you'll need to keep up with any changes in those standards yourself.

Hey, thank you for the quick reply!

Excluding Generic from Generic is of course not that useful, as in that case the whole block could be removed, but that's not a concern for the engine itself.

Thanks for clearing that up! What I wonder now is: does that also exclude rules from the other standards that follow the mentioned block that are inherited from Generic? That would explain the near zero errors then.

That's up to you, but it will increase your maintenance burden if you want to use predefined standards as you'll need to keep up with any changes in those standards yourself.

Yes, I am aware of that. I have not yet found and ideal route and decided how to proceed in the future. (I'm opposing most of the PSR/PER standards, so I have to run custom config)

Excluding Generic from Generic is of course not that useful, as in that case the whole block could be removed, but that's not a concern for the engine itself.

Thanks for clearing that up! What I wonder now is: does that also exclude rules from the other standards that follow the mentioned block that inherit from Generic? That would explain the near zero errors then.

Excludes work for the complete ruleset, as otherwise, if you'd include multiple rulesets which include the same sniff and would only exclude that particular sniff from one, you'd still get the rule included, which would then be reported as a bug here again ;-)
You can always check what is included by running phpcs -e (or phpcs --standard=... -e). -e "explains" the ruleset.
If you do that without the errant exclude on the example ruleset you gave above, you would see that the ruleset includes 98 sniffs, 80 from Generic, 17 from PEAR and 1 from Squiz.
With the errant exclude included in the file, this changes to 18 sniffs, 17 from PEAR and 1 from Squiz. (and none from Generic)

That's up to you, but it will increase your maintenance burden if you want to use predefined standards as you'll need to keep up with any changes in those standards yourself.

Yes, I am aware of that. I have not yet found and ideal route and decided how to proceed in the future. (I'm opposing most of the PSR/PER coding standards, so I have to run custom config)

I feel your pain ;-)

Ok that clears up the confusion! (you can probably imagine my shock when I found that superfluous line and ran phpcs again...)

I feel your pain ;-)

Haha thank you! It's only gotten worse since the PHP 8.4 alpha came out and the abandonment of phan, which is why I started revamping the phpcs config in first place...
Anyway, I think this can be closed then. Again, thank you for your time and work!

Haha thank you! It's only gotten worse since the PHP 8.4 alpha came out and the abandonment of phan, which is why I started revamping the phpcs config in first place...

What with phan being abandoned and revamping the PHPCS config, you may want to consider adding PHPCompatibility into the mix as well ;-) (Pro-tip: use dev-develop for now until v 10 has been released)

What with phan being abandoned and revamping the PHPCS config, you may want to consider adding PHPCompatibility into the mix as well ;-) (Pro-tip: use dev-develop for now until v 10 has been released)

Oh! Thanks for the recommendation, I will definitely look into this!


Authentication on the remote device failed: "ERROR-BAD-REQUEST"

Hi Timothee,
Thanks for building this!
I tried to make this work with a Denon receiver (with Spotify Connect).
To get the ip address and port I ran
avahi-browse -d local _spotify-connect._tcp --resolve
Among other things this gave me:
   address = [xxx.yyy.zzz.aaa]
   port = [80]
   txt = ["CPath=/spotify" "VERSION=1.0"]

I had to change http://{ip}:{port}/SpotifyConnect to http://{ip}:{port}/spotify to have the tool see the receiver.
After that fix, it unfortunately failed at authentication with the following error:
thread 'main' panicked at 'Authentication on the remote device failed: "ERROR-BAD-REQUEST"',

Will try to debug this once I have more time. Maybe other folks have more luck?

Hi @hillstub!
Thank you for testing the project on your Denon receiver. Too bad it does not work!
I had a look to the Spotify ZeroConf documentation and indeed, the path is not hard coded and can change. I added an optional parameter to take it into account. By the way, librespot uses / as path, but does not check it so everything works. I still set / as the default path.

According to the documentation, ERROR-BAD-REQUEST means "Web server problem or critically malformed request". That's not good...
I saw in the documentation that you can provide an optional version parameter to the requests. If the  Spotify SDK in Denon receiver is backward compatible, it could help to give the version. librespot indicates version 2.7.1. The documentation speaks about 2.9.0. Maybe you can modify src/net.rs and test both version number:
// [...]
    let response = minreq::get(base_url)
        .with_param("action", "getInfo")
        .with_param("version", "2.7.1")  // add this line and test both 2.7.1 and 2.9.0
        .send()?;
// [...]
    let response = minreq::post(base_url)
        .with_header("Content-Type", "application/x-www-form-urlencoded")
        .with_param("action", "addUser")
        .with_param("version", "2.7.1")  // add this line and test both 2.7.1 and 2.9.0
        .with_param("userName", username)
        .with_param("blob", encrypted_blob)
        .with_param("clientKey", my_public_key)
        .send()?;
// [...]

If this does not work, I have another idea. But I need to change code first.

By the way, can you send the result of the following command:
curl -X GET http://IP:PORT/spotify?action=getInfo

It could help to understand how the Denon receiver is working. You can redact deviceID or any other personal information.

Hi Timothee,
Thanks for your reply! I retrieved the device info which shows it's using version 2.7.1:
{
    "status": 101,
    "statusString": "OK",
    "spotifyError": 0,
    "version": "2.7.1",
    "deviceID": "REDACTED",
    "remoteName": "Denon AVR-X1600H",
    "activeUser": "REDACTED",
    "accountReq": "DONTCARE",
    "deviceType": "AVR",
    "publicKey": "REDACTED",
    "brandDisplayName": "Denon",
    "modelDisplayName": "Denon AVR-X1600H",
    "libraryVersion": "3.55.23-g85f0da1e",
    "resolverVersion": "0",
    "groupStatus": "NONE",
    "tokenType": "accesstoken",
    "clientID": "REDACTED",
    "productID": 24,
    "scope": "streaming",
    "availability": "",
    "voiceSupport": "NO"
}

When I added this version number to the different request, I'm still getting the same error.
I forgot to tell yesterday that I do get emails from Spotify about a login attempt - so at least something is happening at the Spotify backend.

From the documentation you mentioned it seemed that tokenType is also a mandatory field. In the add_user function,  I added the following:
        .with_param("tokenType", "default")

It now shows the following error:
Found `Denon AVR-X1600H`. Trying to connect...
thread 'main' panicked at 'Authentication on the remote device failed: "ERROR-LOGIN-FAILED"', src/main.rs:65:6
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

(and I don't seem to get an email from Spotify about a login attempt)

I set up MITMProxy to intercept the traffic between the official Spotify app and the receiver. This is the addUser request in curl format:
curl --compressed -H 'Connection: keep-alive' -H 'Content-Type: application/x-www-form-urlencoded' -H 'Keep-Alive: 0' -H 'User-Agent: Spotify/REDACTED' -X POST http://{IP}/spotify -d
'action=addUser
&userName=REDACTED
&blob=REDACTED
&clientKey=
&tokenType=accesstoken
&loginId=REDACTED
&deviceName=REDACTED
&deviceId=REDACTED
&version=2.7.1'

Thanks for the getInfo and the addUser interception!

I forgot to tell yesterday that I do get emails from Spotify about a login attempt - so at least something is happening at the Spotify backend.

(and I don't seem to get an email from Spotify about a login attempt)

The tool I created log you on Spotify to get reusable credentials. So, even if the login failed on your receiver, you should have made a successful connection to Spotify in the tool. If you don't see successful connection now, it is certainly because the reusable credentials are cached. If the cache is present, the connection to Spotify is not made. You can try to delete the cache ($HOME/.cache/spotify-connect/credentials.json) to see what exactly triggers an email from Spotify.

It seems that your receiver accept token as a form of authentication. I didn't have enough time to implement it, but I pushed some changes to prepare for token authentication.
And there is something new you can try: direct username/password authentication, instead of using them to get the reusable credentials. To try it, add the following option on the command line:
spotify-connect --auth-type password IP PORT [PATH]

This new authentication flow is working great with librespot. I hope it would be the case on your hardware too!

I just pushed a new version. Token authentication is implemented.
spotify-connect --auth-type token IP PORT [PATH]

It works great with librespot. But librespot is only relying on the content of the blob. And for now, the different authentication methods only change the way the blob is created. Official hardware may also use other query parameters. Can you try both the code as is, and with a  .with_param("tokenType", "accesstoken") in the net::add_user()?

If it is still not working, I will have to simulate a Spotify Connect endpoint as close as possible to your receiver and log all the messages received from the official Spotify client.
MITM would not be enough, because at least one private key is necessary to decrypt the blob. Getting the private key from the official client or from your receiver is beyond my competences.

I have simulated a Spotify Connect endpoint and used the official Spotify client to communicate with it. This is what I learnt from this experiment.
The presence and value of tokenType in the getInfo request change the way the official client try to authenticate:

If there is no tokenType or if its value is default, the client construct a blob with what I call reusable credentials, encrypt it and send it with the clientKey (necessary to decrypt the blob on the other side).
If tokenType is accesstoken, the client does not send a clientKey. So, the blob is not encrypted. I suspect that the blob field is populated with the token directly (at least, they look similar). But "tokenType": "accesstoken" alone is not enough. A clientId field should be present. The value should be a valid clientId (one can ask for a clientId in the Spotify dashboard). Giving the clientId from the official Spotify client does not work. Perhaps there is a clientId verification on Spotify servers (or a blacklist in the official client) to avoid usurpation. I think the token should be generated for this clientId, with the specified scope.

What I don't understand yet is the loginId field in the addUser request. It is different each time, like the token. Are they linked? Or is it simply a unique identifier for this login request?
I will try to make a new version which take everything I noticed into account. But I wanted to write down what I learned first.

Awesome that you did all the research in getting this some steps closer to solving this.
Did you commit the last version? I got the following error when trying access-token:
error: "access-token" isn't a valid value for '--auth-type <AUTH_TYPE>'
	[possible values: reusable, password, token]

Yes, the last version with access-token as been pushed in the middle of the night. Are you up-to-date? It seems your version is on commit https://github.com/TimotheeGerber/spotify-connect/commit/36d5421f37196eef6d745c80697d1e561897b473, while it should be on c236043c79662b543570727c357625307afb981b for the latest version.
You should execute this to get the latest version:
git pull
cargo install --path .

Maybe your git pull failed. It can happen if you had uncommitted changes for example.

Whoops - forgot to run the last command.
It worked! Woot woot! Thank you for solving this!!
The only thing is that once I authenticated and try running the spotify-connect command again (with and without removing credentials.json) it fails with the following error:
thread 'main' panicked at 'Authentication on the remote device failed: "{\"spotifyError\":12,\"status\":202,\"statusString\":\"ERROR-LOGIN-FAILED\"}"', src/main.rs:117:6

It worked! Woot woot! Thank you for solving this!!

At last! This is such a good news!
🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉

The only thing is that once I authenticated and try running the spotify-connect command again (with and without removing credentials.json) it fails with the following error:

Maybe the login attempt fails if you are already logged in. Try to log out, before running the command once again.
According to the documentation, you should be able to log out by sending an empty POST request:
curl -X POST http://<IP>:<PORT>/<PATH>

If it does not work, you can try to turn off and on your receiver to log out.

Thanks, Timothee!
I had to use the following command to log out the user:
curl -X POST -d action=resetUsers http://<IP>:<PORT>/<PATH>

After that it was possible to login again using the spotify-connect command.
In the (near) future, I'll follow your approach to write a C++ library so that I can use this on an ESP32. Will link to your repository as soon as I have something working.


Get the message which started a forum thread (not using bot only endpoints)

Is it somehow possible to get the message, which started a forum thread, without using a bot only endpoint? The following code would theoretically work, but I get the error HTTP 403 Forbidden, {"message": "Nur Bots k\u00f6nnen diesen Endpunkt verwenden", "code": 20002} (only bots can use this endpoint).
I am aware that this could be against Discord's TOS, but I am using it for a research project on my private test server with a test account.
dg.AddHandler(func(s *discordgo.Session, t *discordgo.ThreadCreate) {
	if t.NewlyCreated {
		channel, err := dg.Channel(t.ID)
		if err != nil {
			logrus.Errorln(err)
		}
		message, err := dg.ChannelMessage(channel.ID, channel.LastMessageID)
		if err != nil {
			logrus.Errorln(err)
		}
		fmt.Println(message.Content)
	}
})

I'm sorry, but we cannot assist in ToS breaking actions.


Write-Message.ps1 error

Bug Report
I'm getting an error with Write-Message.ps1 when a PS script is called in sql agent
General Troubleshooting steps

[x ] Verified running latest release of dbatools?
[x ] Verified errors are not related to permissions?
[x ] Can duplicate in new/fresh PowerShell.exe session?

Version Information

Operating System (Name|Version): win 2012 r2
PowerShell Version: 5
SQL Server (Edition|Version): sql2014

Steps to Reproduce

[ ] Attach any screenshots (if possible/allowed)
[ ] Attach logs generated by dbatools (Get-DbatoolsLog)
[x ] Attach output from PowerShell console (if possible/allowed)

Problem to solve
Attached is the log for when it works in the ISE.
The Error I get from the SQL Agent is:
A job step received an error at line 268 in a PowerShell script. The corresponding line is '			Write-Verbose $newMessage
'. Correct the script and reschedule the job. The error information returned by PowerShell is: 'Operation is not valid due to the current state of the object.
In looking at the code it doesn't like the write-verbose in the write-message module.
ps logging.txt
Additional information
I'm not sure why this works in the ISE and not the sql job.
I have tried different sql accounts, but none seem to work (to rule out permissions).
Is this because it is called in a job?  Without the logging to a file it seems to work fine from a job.

Hi cabana,
thank you for reporting this issue.
How have you set up the job? Are you using a PowerShell step? We have bad experiences with that one, especially where odd behavior we cannot reproduce in the shell/ise is concerned.
If that's not the case, please show us what commands you are running to help us with the troubleshooting.
Chrissy wrote a comprehensive blog post on this:
https://dbatools.io/agent/
Cheers,
Fred

I am using a powershell step.
I'll check the blog post.
Thanks!


Pictures names were switched

While looking at
https://clinguin.readthedocs.io/en/latest/clinguin/reference/input.html
I noticed this small mistake. Can easily be verified checking https://github.com/potassco/clinguin/blob/master/docs/domfiles.png

Thank you  @xarxaxdev! I added this in #164


FEAT-#2796: Add spreadsheet API

What do these changes do?

Add spreadsheet API and expose as modin.spreadsheet
Add spreadsheet to setup.py extras so it can be installed using pip install modin[spreadsheet]
Add jupyter notebook tutorial
Add basic testing for spreadsheet API

Changes still needed

(Decided to leave) Cut down documentation on from_dataframe?
(Decided to leave) Move tutorial location?

[x] tests added and passing

Tests have been added to CI under ci.yml and push.yml. Also added modin-spreadsheet to requirements-dev.txt and environment-dev.yml.

@richardlin047 See #6416 about modin.spreadsheet.


Merge Added multi namespace integration test and fix canary image build script

Merge Added multi namespace integration test
Merge fix canary image build script

/approve


Formatting, hygiene, idiomacy

PR description underneath, after I first explain something.
NOTE: Upstream/main did not compile (see undefined var kloggingLogLevel).  As part of merging in upstream to my PR, I assumed this should have been kloggingMinLogLevel (a global).  A test failed after I changed this.  Examining the test, I was more confident in my change, but then found the JSON serialization was broken: I also renamed to kloggingMinLogLevel the field in the JCON configuration class that was kloggingLogLevel so that JSON would find a 1-to-1 correspondence in naming.  I assume this was just a spot missed by commit 248cb0d6aaa2b8304db22706645de89c8f877b41
            it("is changed if set in JSON") {
                kloggingMinLogLevel = INFO
                configureFromJson("""{"kloggingMinLogLevel":"DEBUG"}""")

                kloggingMinLogLevel shouldBe DEBUG
            }

FYI -- Next PR after this from me is to add .editorconfig and 100-character line limits.  I'm working through my queue of commits off a next branch in my repo, so I don't push commits on top of the current PR on the main branch.

IntelliJ reformatted and I accepted
Documentation on single line when it formats that way
Static imports where an explicitness is not required
Destructuring in lambdas where suggested and it clarified the code
Use of implicit it

Adding an extra line after class declarations before the first member
declaration is a style choice to discuss.

RATS
The 100-line limit PR was supposed to be NEXT, but I forgot to pull it from my main branch before pushing merges from upstream.  :(


matching: expose stream info to filter chain matching

Signed-off-by: Kuat Yessenov<EMAIL_ADDRESS>Commit Message: Supply StreamInfo to findFilterChain to allow matching on dynamic metadata and the filter state populated by the listener filters. Context: https://github.com/envoyproxy/envoy/issues/23614
Risk Level: low
Testing: regression (refactor)
Docs Changes: none
Release Notes: none

CC @ggreenway do you want to take a look?

/assign @envoyproxy/envoy-maintainers

/assign-from @envoyproxy/envoy-maintainers

friendly ping @jmarantz , can you take a look? Thank you

@jmarantz Looks like QuicActiveListener, which owns the proof verifier, doesn't actually have Api::Api to expose. The best we could do is Dispatcher?

@yanavlasov I can follow up if I missed some comments. This is just a refactor so seems low risk.


feat(actions/plan): add argument to suppress PR comments.

The plan is available in the job summary (https://github.com/Brightspace/terraform-workflows/pull/18). Thoughts on adding an arg to suppress PR comments?

Could you update the shared workflow as well? https://github.com/Brightspace/terraform-workflows/blob/main/.github/workflows/workflow.yml

:+1:. 03a385ddecd1a27c518102afed302c0b39414269. Will try out the action on the repo I was thinking of applying this on.
Note: I didn't investigate, but the editor was advising something was wrong with matrix:

Seems like editor might be the one that's wrong?

Seems like editor might be the one that's wrong?

They updated the syntax, but still allow strings - the editor is preferring the newer syntax. S'all good.


user log in page

the first page they'll see
functions include:
email, password (credentials before logging in)
sign up button

completed last sprint


setfiletype does not work in packages

Hello!
I have a plugin containing a file ftdetect/foo.vim:
autocmd BufNewFile,BufRead foo setfiletype foo

The plugin is installed in ~/.vim/pack/stuff/start/.
When I edit a file named foo, I expect the filetype to be set to foo.  Actually it is set to conf.
I believe this is because vim's filetype detection uses:
runtime! ftdetect/*.vim

I think that when that line is executed, the plugins in ~/.vim/pack/stuff/start/ are not on the runtimepath.  So Vim falls back to its generic configuration file.
When I change that line to:
runtime! ALL ftdetect/*.vim

– the filetype is set as expected.
Vim 8.0.586.

On Thursday, May 4, 2017 at 10:56:21 AM UTC-5, Andy Stewart wrote:

I believe this is because vim's filetype detection uses:
runtime! ftdetect/*.vim
I think that when that line is executed, the plugins in ~/.vim/pack/stuff/start/ are not on the runtimepath.  So Vim falls back to its generic configuration file.
When I change that line to:
runtime! ALL ftdetect/*.vim
– the filetype is set as expected.
Vim 8.0.586.

Hmm, that will also search in "opt" packages. I don't think that's wanted unless the user has used packadd already in which case it will be in the runtimepath. Probably it should just search the "start" packages and then the runtime. How is this done? Does it need two runtime commands, first "runtime! START ftdetect/.vim" followed by "runtime! ftdetect/.vim" to pick up the runtimepath files?

How about adding following lines to your .vimrc? (not tested)
filetype plugin indent off
packloadall
filetype plugin indent on

Does it need two runtime commands, first "runtime! START ftdetect/.vim" followed by "runtime! ftdetect/.vim" to pick up the runtimepath files?

According to the :runtime docs, that would do it.  And indeed it works for me.
When [where] is omitted only 'runtimepath' is used.
Other values:
	START	search under "start" in 'packpath'
	OPT 	search under "opt" in 'packpath'
	PACK	search under "start" and "opt" in
		'packpath'
	ALL	first use 'runtimepath', then search
		under "start" and "opt" in 'packpath'

Alternatively the :runtime command could be updated to accept two "where" arguments, e.g. :runtime! RUNTIME START ftdetect/*.vim.  But that's more complicated than just calling :runtime! twice.
@k-takata That doesn't solve the problem, at least for me.  And I feel this should be addressed by vim rather than worked around in users' vimrc configs.

I cannot reproduce this (in Vim 8.0.559); I believe this code ensures that ftdetect scripts from pack directories are sourced.

I tried with Vim 8.0.0596 and couldn't reproduce.
@airblade Could you show your (minimal) .vimrc to reproduce?

~/.vim/vimrc:
filetype plugin on

~/.vim/pack/stuff/start/foo/ftdetect/foo.vim:
autocmd BufNewFile,BufRead foo setfiletype foo

$ vim foo
:verbose set ft?

Expected: foo
Actual: foo
filetype plugin on executes $VIMRUNTIME/filetype.vim, but filetype.vim doesn't set the file type to anything (proved by echoing the file type at the end of filetype.vim).  This means that pack/stuff/start/foo/ftdetect/foo.vim is not on the runtime path then.
Therefore something else (I don't know the mechanism) must subsequently execute pack/stuff/start/foo/ftdetect/foo.vim (which sets the file type to the expected value).
Furthermore:
$ echo "#" > foo
$ vim foo
:verbose set ft?

Expected: foo
Actual: conf
$VIMRUNTIME/filetype.vim sets the file type to the generic conf.  This means that pack/stuff/start/foo/ftdetect/foo.vim is not on the runtime path then.
Therefore when the something-else subsequently executes pack/stuff/start/foo/ftdetect/foo.vim, the setfiletype foo has no effect.
Admittedly I don't understand the "something-else" mechanism which detects the foo file type after $VIMRUNTIME/filetype.vim has already run.  But it seems to me that $VIMRUNTIME/filetype.vim should be aware of packages in ~/.vim/pack/start when it executes.  Currently it isn't.

Ah, I can reproduce this now. And moving ~/.vim/pack/stuff/start/foo/ftdetect/foo.vim to ~/.vim/ftdetect/foo.vim fixes the problem, so it's clearly related to the detection script being in a pack directory.
The problem appears to be the ordering of the :autocmd filetypedetect; the code I mentioned sources the additional pack ftdetect scripts, so their autocmds get appended. However, $VIMRUNTIME/filetype.vim already finished execution, so the usual fallback detections (inspecting file contents via scripts.vim, and the generic configuration one) are now evaluated before the detections from the pack plugins!
:autocmd filetypedetect
[...]
*         if !did_filetype() && expand("<amatch>") !~ g:ft_ignore_pat    && (getline(1) =~ '^#' || getline(2) =~ '^#' || getline(3) =~ '^#'^I|| getline(4) =~ '^#' || getline(5) =~ '^#') |   setf conf | endif
[...]
foo       setf foo

That also explains why your first command (vim foo) gives the correct filetype: This is an empty file, so the fallbacks do not apply.
So, the current implementation only works when the ordering of the detection doesn't matter. That's not what the user expects; the plugin location (pack vs. default) should not matter. It's a bug, similar to #1680 which I've reported.


🐛 Bug Report: TechDocs does not replace #{{values...}} in TechDocs rendering

📜 Description
When following the guide here: https://backstage.io/docs/features/techdocs/how-to-guides#how-to-add-the-documentation-setup-to-your-software-templates the software template documentation shows up nicely in the documentation listing but when going to the documentation itself, the values are not replaced anymore. See screenshots below.
👍 Expected behavior
The dynamic values are also replaced in the documentation page
👎 Actual Behavior with Screenshots
Documentation list view:

The actual documentation page:

👟 Reproduction steps

Create software template
Follow instructions here https://backstage.io/docs/features/techdocs/how-to-guides#how-to-add-the-documentation-setup-to-your-software-templates

📃 Provide the context for the Bug.
No response
🖥 Your Environment
TechDocs builder, generator and publisher are done locally.
OS:   Darwin 22.3.0 - darwin/arm64
node: v16.19.0
yarn: 1.22.19
cli:  0.22.5 (installed)
backstage:  1.12.1
Dependencies:
@backstage/app-defaults                                   1.2.1
@backstage/backend-app-api                                0.4.1
@backstage/backend-common                                 0.17.0, 0.18.3
@backstage/backend-dev-utils                              0.1.1
@backstage/backend-plugin-api                             0.5.0
@backstage/backend-tasks                                  0.5.0
@backstage/backend-test-utils                             0.1.35
@backstage/catalog-client                                 1.4.0
@backstage/catalog-model                                  1.2.1
@backstage/cli-common                                     0.1.12
@backstage/cli                                            0.22.5
@backstage/config-loader                                  1.1.9
@backstage/config                                         1.0.7
@backstage/core-app-api                                   1.6.0
@backstage/core-components                                0.12.5
@backstage/core-plugin-api                                1.5.0
@backstage/dev-utils                                      1.0.13
@backstage/errors                                         1.1.5
@backstage/eslint-plugin                                  0.1.2
@backstage/integration-aws-node                           0.1.2
@backstage/integration-react                              1.1.11
@backstage/integration                                    1.4.3
@backstage/plugin-api-docs                                0.9.1
@backstage/plugin-app-backend                             0.3.43
@backstage/plugin-auth-backend                            0.18.1
@backstage/plugin-auth-node                               0.2.12
@backstage/plugin-catalog-backend-module-aws              0.1.17
@backstage/plugin-catalog-backend-module-bitbucket-server 0.1.8
@backstage/plugin-catalog-backend-module-msgraph          0.5.2
@backstage/plugin-catalog-backend                         1.8.0
@backstage/plugin-catalog-common                          1.0.12
@backstage/plugin-catalog-graph                           0.2.28
@backstage/plugin-catalog-import                          0.9.6
@backstage/plugin-catalog-node                            1.3.4
@backstage/plugin-catalog-react                           1.4.0
@backstage/plugin-catalog                                 1.9.0
@backstage/plugin-github-actions                          0.5.16
@backstage/plugin-jenkins-backend                         0.1.33
@backstage/plugin-jenkins-common                          0.1.14
@backstage/plugin-jenkins                                 0.7.15
@backstage/plugin-kubernetes-common                       0.6.1
@backstage/plugin-org                                     0.6.6
@backstage/plugin-permission-backend                      0.5.18
@backstage/plugin-permission-common                       0.7.4
@backstage/plugin-permission-node                         0.7.6
@backstage/plugin-permission-react                        0.4.11
@backstage/plugin-proxy-backend                           0.2.37
@backstage/plugin-scaffolder-backend-module-cookiecutter  0.2.18
@backstage/plugin-scaffolder-backend                      1.12.0
@backstage/plugin-scaffolder-common                       1.2.6
@backstage/plugin-scaffolder-node                         0.1.1
@backstage/plugin-scaffolder-react                        1.2.0
@backstage/plugin-scaffolder                              1.12.0
@backstage/plugin-search-backend-module-elasticsearch     1.1.4
@backstage/plugin-search-backend-module-pg                0.5.4
@backstage/plugin-search-backend-node                     1.1.4
@backstage/plugin-search-backend                          1.2.4
@backstage/plugin-search-common                           1.2.2
@backstage/plugin-search-react                            1.5.1
@backstage/plugin-search                                  1.1.1
@backstage/plugin-sonarqube-backend                       0.1.8
@backstage/plugin-sonarqube-react                         0.1.4
@backstage/plugin-sonarqube                               0.6.5
@backstage/plugin-techdocs-backend                        1.6.0
@backstage/plugin-techdocs-module-addons-contrib          1.0.11
@backstage/plugin-techdocs-node                           1.6.0
@backstage/plugin-techdocs-react                          1.1.4
@backstage/plugin-techdocs                                1.6.0
@backstage/plugin-user-settings                           0.7.1
@backstage/release-manifests                              0.0.9
@backstage/test-utils                                     1.2.6
@backstage/theme                                          0.2.18
@backstage/types                                          1.0.2
@backstage/version-bridge                                 1.0.3
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, I don't have time to work on this right now

Yeah that is the one with small modifications to owner etc. But basically the same template.

@drodil This software template is supposed to be used as part of the scaffolder which should be creating a new repository or PR for you with that template filled in. If it's showing up in techdocs, I assume that your template process is not working correctly rather than it being anything related to techdocs because these should be replaced way before the techdocs engine goes about creating and publishing your docs.

@jtreher no, this is supposed to be the documentation of that template, not the documentation the template creates for some repository. And as it's working in the list view of the documentation, there's something wrong with the techdocs view not showing those values.

Hi @drodil, TechDocs pulls those values from the mkdocs.yml file when it generates. On Discord you said those weren't being populated: https://discord.com/channels/687207715902193673/1091341655535267850/1092317347567636640
TechDocs will only work with what it has and in this case it's not the culprit, but I'm happy to be proven wrong.
Could you post the Template's YAML as well as YAML for the mkdocs.yml, please? That could help us figure this out


Promote to release-candidate after every bundle build

Signed-off-by: Yilin Zhang<EMAIL_ADDRESS>Description
Currently, all the files will be uploaded to builds/test-release-candidates folder.
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #1378 (604237d) into main (dd1560d) will increase coverage by 0.38%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main    #1378      +/-   ##
============================================
+ Coverage     94.02%   94.40%   +0.38%
============================================
  Files           136      119      -17
  Lines          3011     2930      -81
  Branches          8        0       -8
============================================
- Hits           2831     2766      -65
+ Misses          172      164       -8
+ Partials          8        0       -8

Impacted Files
Coverage Δ

src/system/temporary_directory.py
83.87% <0.00%> (-12.91%)
:arrow_down:

src/system/os.py
92.30% <0.00%> (-7.70%)
:arrow_down:

src/jenkins/BuildManifest.groovy

tests/jenkins/jobs/GetManifestSHA_Jenkinsfile

tests/jenkins/jobs/Hello_Jenkinsfile

src/jenkins/InputManifest.groovy

...sts/jenkins/jobs/ArchiveAssembleUpload_Jenkinsfile

src/jenkins/Messages.groovy

tests/jenkins/jobs/DetectDockerImage_Jenkinsfile

tests/jenkins/jobs/BuildAssembleUpload_Jenkinsfile

... and 9 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 dd1560d...604237d. Read the comment docs.

Please make sure that the new output will handle these cases:

.../release-candidates/core/opensearch/1.2.2/opensearch-min-1.2.2-linux-x64.tar.gz
.../release-candidates/core/opensearch/1.2.2/opensearch-min-1.2.2-linux-arm64.tar.gz
.../snapshots/core/opensearch/1.2.2-SNAPSHOT/opensearch-min-1.2.2-SNAPSHOT-linux-x64-latest.tar.gz
.../snapshots/core/opensearch/1.2.2-SNAPSHOT/opensearch-min-1.2.2-SNAPSHOT-linux-arm64-latest.tar.gz

I think we've got the first case, but we need the snapshot ones too

Can we try to move this forward, please?

@zylzulu will review when the build is green and the CR is ready

Please make sure that the new output will handle these cases:
* .../release-candidates/core/opensearch/1.2.2/opensearch-min-1.2.2-linux-x64.tar.gz

* .../release-candidates/core/opensearch/1.2.2/opensearch-min-1.2.2-linux-arm64.tar.gz

* .../snapshots/core/opensearch/1.2.2-SNAPSHOT/opensearch-min-1.2.2-SNAPSHOT-linux-x64-latest.tar.gz

* .../snapshots/core/opensearch/1.2.2-SNAPSHOT/opensearch-min-1.2.2-SNAPSHOT-linux-arm64-latest.tar.gz

I think we've got the first case, but we need the snapshot ones too

Hi @peternied , @dblock,
currently the min and bundle are being uploaded to build/test-release-candidate folder (I'll change to release-candidates before I merge my code).
Regarding snapshots from where do I retrieve them?

Please make sure that the new output will handle these cases:
* .../release-candidates/core/opensearch/1.2.2/opensearch-min-1.2.2-linux-x64.tar.gz

* .../release-candidates/core/opensearch/1.2.2/opensearch-min-1.2.2-linux-arm64.tar.gz

* .../snapshots/core/opensearch/1.2.2-SNAPSHOT/opensearch-min-1.2.2-SNAPSHOT-linux-x64-latest.tar.gz

* .../snapshots/core/opensearch/1.2.2-SNAPSHOT/opensearch-min-1.2.2-SNAPSHOT-linux-arm64-latest.tar.gz

I think we've got the first case, but we need the snapshot ones too

Hi @peternied , @dblock, currently the min and bundle are being uploaded to build/test-release-candidate folder (I'll change to release-candidates before I merge my code. Not making any code changes since I can use this for testing ). Regarding snapshots from where do I retrieve them? Also I believe snapshots only applies to min here

Check out https://github.com/opensearch-project/opensearch-build/blob/main/jenkins/opensearch/distribution-build.jenkinsfile#L50, which calls publish-snapshot to Maven. You'll probably want to publish around there.

Please make sure that the new output will handle these cases:
* .../release-candidates/core/opensearch/1.2.2/opensearch-min-1.2.2-linux-x64.tar.gz

* .../release-candidates/core/opensearch/1.2.2/opensearch-min-1.2.2-linux-arm64.tar.gz

* .../snapshots/core/opensearch/1.2.2-SNAPSHOT/opensearch-min-1.2.2-SNAPSHOT-linux-x64-latest.tar.gz

* .../snapshots/core/opensearch/1.2.2-SNAPSHOT/opensearch-min-1.2.2-SNAPSHOT-linux-arm64-latest.tar.gz

I think we've got the first case, but we need the snapshot ones too

Hi @peternied , @dblock, currently the min and bundle are being uploaded to build/test-release-candidate folder (I'll change to release-candidates before I merge my code. Not making any code changes since I can use this for testing ). Regarding snapshots from where do I retrieve them? Also I believe snapshots only applies to min here

Check out https://github.com/opensearch-project/opensearch-build/blob/main/jenkins/opensearch/distribution-build.jenkinsfile#L50, which calls publish-snapshot to Maven. You'll probably want to publish around there.

Looking at the above code:
The buildManifest just builds the snapshot but doesn't upload it anywhere. Its the publish-snapshot that uploads the artifacts to maven.
https://github.com/opensearch-project/opensearch-build/blob/main/jenkins/opensearch/distribution-build.jenkinsfile#L45-L47
Should I directly upload from there to s3? Also what about arm64? While I ran this to see the generated artifacts I did not see anything generated for arm64 here.

@gaiksaya I think it's perfectly OK to do the snapshot uploading as part of another PR, and we can discuss options there; (2) seems like the better thing to do

@gaiksaya I think it's perfectly OK to do the snapshot uploading as part of another PR, and we can discuss options there; (2) seems like the better thing to do

Created the issue https://github.com/opensearch-project/opensearch-build/issues/1442 to address the min snapshots uploading part


Reduce CPU overhead by replacing while loop with await

Reduce CPU overhead by replacing while loop with await. The previous version waits for finishing sending data by using a while loop. In that way, cpu overhead would be pretty high. Thus, instead of waiting for finishing sending data with a while loop, we use a BlockingQueue to notice it when all data have been sent out successfully.

Added a few comments. Thanks! Also don't forget the UT :)

The existing UTs which are write related should cover this class.

alluxio-bot, merge this please


Authorization

Is your feature request related to a problem? Please describe.
This story is related to the authorization part of create metering point.
Might be part of API management. Talk to Rene.
Describe the solution you'd like.

[ ] JWT middleware
[ ] Add interface: IUserIdentity
[ ] Add factory, which can create a specific instance of IUserIdentity on the basis of ClaimsPrinciple
[ ] Mock FakeIdentity for test purposes

Definition of done

[ ] Demonstrate request with both valid and invalid JWT token:

[ ] valid token: 200
[ ] invalid token: 401

[ ] Demonstrate that claims from JWT token is transferred to the specific UserIdentity

We will look into it again if needed, for now we will close it.


Add logo when start server

Pull Request Test Coverage Report for Build 745

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 93.052%

Totals

Change from base Build 742:
0.0%

Covered Lines:
750

Relevant Lines:
806

💛  - Coveralls


Keybinding to open an image

I know I can open images my pressing Return. I want to map o (open) to achieve the same behaviour.
I tried with o: Return in my keys.conf file but I (obviously) doesn't work. Is there a workaround for this? Thanks

Meaning you would like o in the library to behave like Return? It is simple for it to behave like l, the binding would then be o: scroll_lib l, but actually also closing the library is currently not possible.

Ok. Thanks! Will use o: scroll_lib l then.

I there a similar trick for thumbnail mode?

Unfortunately not, I actually think this is a more general problem. The Return key is used, as it emits a signal in Gtk. There are other keys, which have internal functionality and aren't implemented using the standard command interface. I think this could be solved in general by adding functionality similar to vim's :map command, not sure where this would go in the config though.

That's a good idea!

The initial issue has been fixed in the Qt port with the :open-selected command within this issue for both library and thumbnail mode. I have not found a different usecase for the :map command yet, although it would not be too difficult to implement. Feel free to open an issue there if you can think of more general usecases for the :map command. Sorry for the version chaos, I'm trying to clean up :smile:


Set up SSO for Costal Carolina University

Emailed the xml metadata for setting up their SSO. It's a non-federated set up.

Created PT ticket for this: https://www.pivotaltracker.com/story/show/177006996


feat: testing mode from non-main slsa-framework/slsa-github-generator branches

Allow verifying provenances from the slsa-framework/slsa-github-generator branches.
This is useful during in development.
We could also allow the tester to customize the repo, to perhaps their own fork. example:
SLSA_VERIFIER_TESTING_ALTERNATE_SOURCE_REPO="ramonpetgrave64/slsa-verifier" \
    go run . verify-artifact ...

Testing

Added unit tests
manually invoking against provenance and artifacts from a test workflow run

https://github.com/slsa-framework/slsa-github-generator/actions/runs/10308515370

also verifying within the same workflow

https://github.com/slsa-framework/slsa-github-generator/actions/runs/10308515370/job/28536184530#step:6:1

@ianlewis @laurentsimon

Is this to support running slsa-verifier in slsa-github-generator pre-submits? I kind of thought we did this already but maybe I'm misremembering?

@ianlewis not for pre-submits, or pull_request events, but for push events, since id-token isn't available for PRs. And so far it seems  not yet nresolved.

https://github.com/slsa-framework/slsa-github-generator/issues/131

So I might be testing changes on a separate branch "ramoneptgrave64-my-tests" that exists on the slsa-framework/slsa-github-generator repo.

Additional discussion, considering using an alternative identity token within PRs

https://github.com/slsa-framework/slsa-github-generator/pull/3777#discussion_r1795254767


It should be possible to customize .form-control:focus (border-color & box-shadow) using CSS variables.

Prerequisites

[X] I have searched for duplicate or closed feature requests
[X] I have read the contributing guidelines

Proposal
My wish is that the bootstrap team will include the option to customize .form-control:focus (border-color & box-shadow) using CSS variables.

Motivation and context
Customizing the default Bootstrap style with CSS variables is not only helpful but also easier.

I made some changes to the form-control.scss file to customize the .form-control class when it's focused. I added CSS variables to change the border-color and box-shadow properties for better customization. However, since there was no HTML file available to test my changes, I created my own custom HTML file to check if my changes were working as intended.
// Define the variables for the form control focus state
$form-control-border-color: var(--form-control-border-color);
$form-control-box-shadow: var(--form-control-box-shadow);
.form-control {
// styles for form control
}
.form-control:focus {
border-color: $form-control-border-color;
box-shadow: $form-control-box-shadow;
}
for the custom html file i've made sure to use the
:root {
--form-control-border-color: #ccc;
--form-control-box-shadow: 0 0 5px rgba(0, 0, 0, 0.5);
}
  .form-control:focus {
    border-color: var(--form-control-border-color);
    box-shadow: var(--form-control-box-shadow);
  }

but after reviewing the screenshot i made other changes to the test and it looks like that now
:root {
--form-control-border-color: var(--form-control-border-color);
--form-control-box-shadow: var(--form-control-box-shadow);
}
  .form-control:focus {
    border-color: rgb(255, 15, 15);

box-shadow: 0 0 0 0.2rem rgba(2, 255, 2, 0.677)
}


gamma-control-v1: fix use-after-free in gamma_control_handle_set_gamma

gamma_control_send_failed destroys gamma_control.

Let's wait for @minus7 to test this

Doesn't crash anymore (though I'm not sure what exactly caused it before), but gamma isn't re-applied after the monitors wake up from DPMS (have to restart Redshift)

Hmm, makes sense. This will require more work. Can you open an issue about it, @minus7?


Better integrate with Material controls

Is your feature request related to a problem? Please describe.
The material theme is not matching yours:

Describe the solution you'd like
By allowing <mat-form-field> around your control, material theming will be applied
    <mat-form-field>
      <daterangepicker
        class="col-md-12 col-lg-12 form-control"
        [options]="daterangepickerOptions"
        (rangeSelected)="dateChanged($event)">
      </daterangepicker>
    </mat-form-field>

The code above generates the followwing error:
mat-form-field must contain a MatFormFieldControl.
Maybe because matInput directive is maybe not present.
Describe alternatives you've considered
Providing manually full HTML/CSS theming generated by Material
Let me know if I missed something.

Another way would be to provide a directive like this:
    <mat-form-field>
      <input daterangepicker
        class="col-md-12 col-lg-12 form-control"
        [options]="daterangepickerOptions"
        (rangeSelected)="dateChanged($event)">
      </input>
    </mat-form-field>

I used a workaround to display a material input field in the UI and link your date/time picker control with it by cheating with the CSS:

yeah CSS is kept open for that purpose. Apparently creating headless UI is not that streight forward in angular. I am thinking of creating a pure js headless version of datetimerangepicker so people can use any css and their brand theme to build UI.


Changes for AquaScan Issues

What this PR does / why we need it:
https://github.ibm.com/IBMPrivateCloud/roadmap/issues/53241
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Release note:

/retest


System spell checker not working on Mac

MacOS has an amazing system spell checker and auto complete system. But somehow it doesn't work with Blogly.

Fixed in commit c08f01aee515403e3a7e1eb183b9658265184196.


Support "Enum"-like types semi-extensibly

We should be able to support common types that are enums or enum-like, including:

StructuringElement, used in the labeling.cca Op
OutOfBoundsFactory, of which many implementations could be reduced to an enum.

This issue may also be related to a segmentation fault when trying to initialize net.imagej.ops.deconvolve.RichardsonLucyTV.


Mismatch between expected 1024000 and actual 1024512 KiB size.

I downloaded weigths from https://huggingface.co/google/gemma-2b-cpp/blob/main/2b-pt.sbs but can't make them run:
$ ./gemma --tokenizer ~/Downloads/gemma-2b-pt/tokenizer.spm --model 2b-it --weights ~/Downloads/gemma-2b-pt/2b-pt.sbs
Mismatch between expected 1024000 and actual 1024512 KiB size. Please see README.md on how to update the weights.

Am I missing some flags? I tried compiling with cmake -B build -DWEIGHT_TYPE=hwy::bfloat16_t but that didn't seem to have any effect.

Sorry about the trouble. The weights have changed and they appear not to be synced across all sources. Are you able to download the v3 version from Kaggle, or the model there prefixed with "1.1" which also contain the updated size?

Hi @ticcky , Could you please confirm, if the issue is resolved. If yes, please feel free to move this issue to closed status


How about upgrade framework 4.6.1 to 4.6.2?

There are several projects targeting framework 4.6.1. I know it's the minimal version that supports standard 2.0. However it has been out of support for a year. And microsoft also not recommend to use it for standard 2.0. So would it be better to upgrade these projects?
https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-0

The versions listed here represent the rules that NuGet uses to determine whether a given .NET Standard library is applicable. While NuGet considers .NET Framework 4.6.1 as supporting .NET Standard 1.5 through 2.0, there are several issues with consuming .NET Standard libraries that were built for those versions from .NET Framework 4.6.1 projects. For .NET Framework projects that need to use such libraries, we recommend that you upgrade the project to target .NET Framework 4.7.2 or higher.

We are targeting the minimum legacy .NET version Avalonia can work with, so unless there is a specific feature that we absolutely need, there is no point in upgrading.


Add option to auto-publish new snapshot as feed version

It's a bit confusing for new users of the GTFS editor to understand that in order to create a new feed version they must:

Create a new snapshot and
Publish the new snapshot as a feed version (a separate action)

Depending on where the user creates the snapshot, the button to publish snapshot as feed version may not even be visible in the UI (e.g., if the camera button in the editor is clicked). We need to add an option to the create snapshot modal to allow auto-publish of the snapshot as a feed version. It's one of the most common workflows we have for snapshots, so it should be an option.

:tada: This issue has been resolved in version 4.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


deno: 1.13.2 -> 1.14.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for deno is: "A secure runtime for JavaScript and TypeScript"
meta.homepage for deno is: "https://deno.land/"
meta.changelog for deno is: "https://github.com/denoland/deno/releases/tag/v1.14.0"
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/1wwym0vhhkw6jg4brd6z8zrbxy2hwdn0-deno-1.14.0/bin/deno passed the binary check.

1 of 1 passed binary check by having a zero exit code.

1 of 1 passed binary check by having the new version present in output.

found 1.14.0 with grep in /nix/store/1wwym0vhhkw6jg4brd6z8zrbxy2hwdn0-deno-1.14.0

found 1.14.0 in filename of file in /nix/store/1wwym0vhhkw6jg4brd6z8zrbxy2hwdn0-deno-1.14.0

directory tree listing: https://gist.github.com/98b02a070e0cb766751286f265b4db1d

du listing: https://gist.github.com/259f6534859cdd4ce44c33ff8d24a910

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
0 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
deno

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/1wwym0vhhkw6jg4brd6z8zrbxy2hwdn0-deno-1.14.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A deno https://github.com/r-ryantm/nixpkgs/archive/507dcc10b25c82ed643bbef65bbdf1891c111f27.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/1wwym0vhhkw6jg4brd6z8zrbxy2hwdn0-deno-1.14.0
ls -la /nix/store/1wwym0vhhkw6jg4brd6z8zrbxy2hwdn0-deno-1.14.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

deno

Maintainer pings
cc @06kellyjac for testing.

Result of nixpkgs-review pr 137986 run on x86_64-linux 1

1 package failed to build:

deno

What is weird?

The deno built and cached has version 1.13.2 rather than 1.14.0
I copied the shas for src cargo and rustyv8 and did a build and it hit the cache. Also 1.13.2. (Shouldn't happen with that tag and src sha as the Cargo.toml in the cli dir has the correct 1.14.0 version)
I added an "echo hi" so the build would avoid the cache and did a full build. Outputs 1.14.0 correctly

Hmm... I got the correct version from this PR
[nix-shell:~/.cache/nixpkgs-review/pr-137986]$ ./results/deno/bin/deno --version
deno 1.14.0 (release, x86_64-unknown-linux-gnu)
v8 <IP_ADDRESS>
typescript 4.4.2

Result of nixpkgs-review pr 137986 run on x86_64-linux 1

1 package built:

deno

@06kellyjac Does the 1.14.0 version look good for you? Can I merge this?

Yeah looks good. I must have messed something up or had an issue with nixpkgs-review
Manual build worked fine, several other good reports. Please merge :slightly_smiling_face:


azure: use latest sdk and cleanup auth code

hopefully you'll find this helpful no worries if it isn't. this should help with the azure issues in https://github.com/xenolf/lego/issues/457

welp I'm not sure what you want to do about this azure dependency. happy to implement anything you want.

the acmev2 branch is now merged and the Azure SDK is fixed.
Thanks for your contribution.


[FLINK-11388][fs] Add Aliyun OSS recoverable writer

What is the purpose of the change
OSS offers persistence only after uploads or multi-part uploads complete.  In order to make streaming uses OSS as sink, we should implement a Recoverable writer. This writer will snapshot and store multi-part upload information and recover from those information when failure occurs
Brief change log

move utility classes to flink-fs-common
add abstract test classes for recoverable writers(s3/oss)
add OSS recoverable writer

Verifying this change
This implementation adds some tests to test logic of recoverable writer. However, in order to run these tests, someone need to have his own Aliyun access key id and access key secret. Then, set environment variables below：
export ARTIFACTS_OSS_ENDPOINT=<Aliyun OSS endpoint to connect to>
export ARTIFACTS_OSS_BUCKET=<Your bucket>
export ARTIFACTS_OSS_ACCESS_KEY=<Your access key id>
export ARTIFACTS_OSS_SECRET_KEY=<Your access secret>
These tests are skipped by default.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

@StefanRRichter Please help to review this PR, thanks!

@flinkbot approve description

@StefanRRichter would you please help review this PR? Thanks :)

Rebase master.

”flink-oss-fs-hadoop-XXX.jar“ built from source code  can‘t   support streaming file sink.
It 's a common error when Flink users use FileSink/StreamingFileSink to upload objets to OSS.we have received many complaints from customers.
This feature would be very useful to Flink users。Specially to the people live in APAC，there are a lot of people often use OSS。
Could we reconsider open this PR again？
@wujinhu @flinkbot @dawidwys @rmetzger @hadronzoo

@kl0u Can we reopen this PR? Some users depend on this feature and I can keep working on it.

@wujinhu I think we can, I can help review and merge.


Cleanup dox mess - correction

unbreak openbsd after 7ac0fe53e a } was missing

r? @alexcrichton
(rust_highfive has picked a reviewer for you, use r? to override)

@bors: r+
FYI I have a PR in the pipeline that uses xargo to compile libc+libcore on targets that do not ship a std component on CI. Hopefully after that's merged you won't have to send these kinds of PRs anymore :)

:pushpin: Commit f8466b6cab3f9f82b36c4ad6e0579f498820764e has been approved by gnzlbg

:hourglass: Testing commit f8466b6cab3f9f82b36c4ad6e0579f498820764e with merge 55622dd95dd3f795152262483a7ebb0e872f0df1...

:broken_heart: Test failed - checks-travis

@bors: retry

:hourglass: Testing commit f8466b6cab3f9f82b36c4ad6e0579f498820764e with merge 666488dc7a588686cce96f0150e619e4b4645683...

:broken_heart: Test failed - checks-cirrus

@semarie Thank you for the PR, I'm closing it because this should be fixed by #1263 , which should prevent this from breaking again, and also generate docs for openbsd (we'll see if the docs part works out).


setting variable value on-demand (at read-time)

I have some variables which should not be updated automatically -- the expense is considerable and they are hardly ever going to be used. Instead, I would like to define a functor computing the value on-demand, when the client asks for it. Is there a way to do it, or is there not because it is not implemented in QUaServer or in open62541 or is this beyond the OPC/UA architecture? Thanks! :)

What do you mean with "the expense is considerable"? Is it in memory or CPU usage? If I remember correctly the open62541 library supports two ways to handle data sources for variables:

Handled internally by the open62541 library, read and write through the open62541 API.

Handled externally,  read and write through user-defined callbacks.

For the QUaServer implementation I use the first approach.

(admittedly an abuse of OPC/UA:) The program is logging messages into circular buffer which would, on-demand, generate latest messages in human-readable form and send them over OPC/UA; the access over OPC/UA would be quite rare in practice (when debugging), periodic publishing seems like waste of resources. I did not measure eaxactly how expensive it would be; likely negligible. It just feels unnecessary.

I still don't fully undestand your use-case, but the phrase "periodic publishing seems like waste of resources" stands up. Are you subscribed throught a client to changes in the server? Because in that case you can tweak the OPC UA subscription (in the client) to control how often receive changes.

Most the time the value of the node would not be read at all. Only sometimes, when debugging, the value would be accessed, at which point it should be built.
https://github.com/juangburgos/QUaServer/blob/1444848a9491e661173cadb3969167cbb26888a2/src/wrapper/quabasevariable.cpp#L50
If the callback setting the current value were added, would it get called before the built value were returned over OPC/UA in the normal (current) way?

You can expriment with that, but as I mentioned, I built QUaServer based on approach 1), therefore I don't know what side effects might have implementing that callback. Other stuff might stop working. Take a look at https://open62541.org/doc/0.3/server.html#data-source-callback

Thanks for the link. It is the value callback which looks what I'm after: "If not NULL, they are called before reading and after writing respectively." As I understand, upon reading request, the callback would get the data from the source, and set the OPC/UA value; the reading would proceed through the normal codepath afterwards. It is still approach 1., only calling the hook right before reading.
I will post my findings here.

Fixed by pr #17


Getting the "root" element?

So you'll have to educate me on this, but I'm unclear if this code does what you want it to (~lines 92-95):
        top_level_elements = Element.objects.filter(level=0) # this is a string not an element object
        for x in top_level_elements:
            if str.lower(x.name) == "start":
                element = x

Are you trying to get the first start Element, or the last one, assigned to the element variable? If you really start supporting multiple dialog roots, won't you have to change this code to account for multiple start Elements? (and how would you do that? At the very least, you might need a break statement here, or otherwise grab the first one back from the queryset).
This also seems like an opportunity to break this code out into its own method and gave it a clarifying name. And of course, add a set of tests (when there are no elements named start, 1 element, multiple, etc.), depending on what is the current use case you're supposed to be supporting.
Right now I think the on_chat_message method breaks if there are no elements named start (line 295, user.last_node=element might throw an exception), but maybe that's not a possible state to be in?

Or, if you're sticking with one dialog tree for now, just add in a TODO comment to refactor that section, when you need to support multiple dialog trees.


CORE-307 - Include MAN Into UK Network Data

:tada: This PR is included in version 4.2.16 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Block hash of putting bucket returns an empty string

This morning I am trying out DeOSS PutBucket API, as shown here. The response returned is 200. But the block hash is an empty string. Screenshot below:

If needed, you can contact me at https://t.me/jimmychu0807. I am also working with @swowk.

I think the bucket creation failed on the server side. Screenshot below. Let me know if there is anything I missed on the above PUT request. Thanks.

Hello Mr. Jimmy, there was a problem with our internal service route parsing, it has been fixed now, you can try again.

I tried it again this afternoon. This is what I got back:

I have renewed the token by sending a /auth? request to get the latest token.
This request has processed for ~7s before sending me back a failed message. I guess the server side is processing, but somehow hits another stumbling blocking.


limit or paginate some results in account

there are some account pages like http://bitshares-explorer.io/#/accounts/cryptobridge or http://open-explorer.io/#/accounts/1.2.0 by the huge number of referrers they have.

added pagination to referrers in this commit: https://github.com/oxarbitrage/open-explorer/commit/4e0b87ee5b8d6d8cffd8a4c1816ce89789a4a551
this will allow to load the heavy referrers account pages fine and probably increase overall performance.


bpf: rename variables with camel-case names

We run checkpatch.pl on the commits touching the bpf/ code, and it complains when edits contain camel-case variable names -- even if they were not introduced by the commit. We could disable this report in the script we use to call checkpatch.pl, but at the same time we do want it to catch the introduction of new camel-case names.
As suggested in https://github.com/cilium/cilium/pull/16447#discussion_r646556442, let's fix the existing variable names once and for all, to avoid contributors to get surprised by the reports.
The number of variables is rather low: srcID, dstID, localID, remoteID, and newEntries.

test-me-please

test-1.21-4.9

test-me-please

test-1.21-4.9
(failed to download the image)

test-me-please

test-me-please

Apologies, I forgot to comment on the failures -_-. There were two flakes, documented as #16399 and #16551, plus some failures on the Conformance tests. Thanks for the new trigger.

test-me-please


ignore views/foreign tables/temporary tables in postgres databases

I've just started using klepto to create a staging database, and run into the problem that the views are interfering with klepto.
there was a PR previously opened, but is now closed: https://github.com/hellofresh/klepto/pull/99

👍


[Request-for-external] Table 27 "Item"  - SetLastDateTimeModified

Can you change procedure SetLastDateTimeModified in table 27 "Item" to global?

Why? You can use system fields below any time:

There appear to be two separate fields:

Some functions in the Base Application are using the Field "Last DateTime Modified" (E.g. XmlPort 5801) which is why the access to the function SetLastDateTimeModified would be great.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


SQL Server will occasionally not add new rows and recognize their changes.

This also happens in SSMS as well (although this has been tested after running ADS). Sometimes, the SQL Server won't recognize new row changes added to the server at all and you have to restart the server entirely as a result. Switching to different versions of ADS does not fix the issue. This only happens shortly after running the latest version of ADS.

Closing issue as it appears to be an issue with the table itself on the server (having all null rows)


Performance on Waymo dataset lower than reported

Hi,
thank you for your great work. It's highly inspired.
I do have a few questions though. I attempted to reproduce results on Waymo Open Datasets but the performance is a bit lower than reported in the paper. I am wondering is it caused by the adaption I made or I missed anything.
What I did are

Follow the preprocessing instruction to process WOD.
Use 20% data to do pre-training (SSL) and training (supervised learning) by setting SAMPLED_INTERVAL['train'] to 5 in both gd_mae_ssl.yaml and gd_mae.yaml.
Set FILTER_EMPTY_BOXES_FOR_TRAIN to False for both pre-training and training in waymo_dataset.yaml. Otherwise I run into RecursionError: maximum recursion depth exceeded in comparison issue because GT boxes containing are always empty.
Batch size. One major difference is that, due to the GPU memory limit, I have to set batch_size*GPUs to 4x8 and 2x8 for pre-training and training, respectively, instead of 8x4 in the paper.

What I obtained are
OBJECT_TYPE_TYPE_VEHICLE_LEVEL_2: [mAP 0.659692] [mAPH 0.655148]
OBJECT_TYPE_TYPE_PEDESTRIAN_LEVEL_2: [mAP 0.705515] [mAPH 0.627452]
OBJECT_TYPE_TYPE_CYCLIST_LEVEL_2: [mAP 0.68869] [mAPH 0.676339]

which is 1~2 points lower than reported in Table 4. Do you think it is caused by the reduction of batch size or it's a normal variation?
Later, I realized that the FILTER_EMPTY_BOXES_FOR_TRAIN (in step 3) can be set as True as in the original code for (supervised) training. But the performance goes very low, like 0.06/0.06 for vehicles, 0.10/0.09 for pedestrian. I am wondering what should this variable be for pre-training and training?
Thanks in advance.

Hi, I have some question on your work.
How can you get the waymo dataset's result?
Because i just can get below result when i run the code for waymo dataset.
2024-04-15 12:24:41,593   INFO  Average predicted number of objects(39987 samples): 100.000
2024-04-15 12:24:44.026785: I tensorflow/stream_executor/platform/default/dso_loader.cc:53] Successfully opened dynamic library libcudart.so.11.0
39987it [00:40, 990.05it/s]
results saved to /home/workspace/jisoocv/GD-MAE/output/kitti_models/graph_rcnn_po/default/eval/epoch_no_number/val/default/final_result/data/detection_pred.bin
2024-04-15 12:25:39,637   INFO
2024-04-15 12:25:41,141   INFO  Result is save to /home/workspace/jisoocv/GD-MAE/output/kitti_models/graph_rcnn_po/default/eval/epoch_no_number/val/default
2024-04-15 12:25:41,141   INFO  Evaluation done.*


Constraint:node and volumes dependency issue

I have a container C that needs to run on a specific node with an associated data container D:
When using Docker-Compose in combination with Docker-swarm, I am not able to start the container.
Snippet of my compose file:
ge:
 volumes_from:
 - ge-settings
 environment:
 - alternate_lsd=/tmp/settings/alternate.lsd
 - "constraint:node==ip-172-31-9-126"
 image: myname/myimage
 container_name: ge
 ports:
 - "8765:8765"

ge-settings:
 image: myname/mydata

Container C will follow D w.r.t. location, which may not satisfy the constraint put on C.
I tried to add a node constraint on D, without effect.
How can this be done?

I can't force it to use any constraints at all, for instance:
Containers: 10
Images: 24
Role: primary
Strategy: spread
Filters: health, port, dependency, affinity, constraint
Nodes: 5
 master: <IP_ADDRESS>:2376
  └ Containers: 2
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 517.6 MiB
  └ Labels: executiondriver=native-0.2, kernelversion=4.1.12-boot2docker, operatingsystem=Boot2Docker 1.9.0 (TCL 6.4); master : 16e4a2a - Tue Nov  3 19:49:22 UTC 2015, provider=virtualbox, storagedriver=aufs
 slave-1: <IP_ADDRESS>:2376
  └ Containers: 4
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 512 MiB / 517.6 MiB
  └ Labels: executiondriver=native-0.2, kernelversion=4.1.12-boot2docker, operatingsystem=Boot2Docker 1.9.0 (TCL 6.4); master : 16e4a2a - Tue Nov  3 19:49:22 UTC 2015, provider=virtualbox, storagedriver=aufs
 slave-2: <IP_ADDRESS>:2376
  └ Containers: 1
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 517.6 MiB
  └ Labels: executiondriver=native-0.2, kernelversion=4.1.12-boot2docker, operatingsystem=Boot2Docker 1.9.0 (TCL 6.4); master : 16e4a2a - Tue Nov  3 19:49:22 UTC 2015, provider=virtualbox, storagedriver=aufs
 slave-3: <IP_ADDRESS>:2376
  └ Containers: 2
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 517.6 MiB
  └ Labels: executiondriver=native-0.2, kernelversion=4.1.12-boot2docker, operatingsystem=Boot2Docker 1.9.0 (TCL 6.4); master : 16e4a2a - Tue Nov  3 19:49:22 UTC 2015, provider=virtualbox, storagedriver=aufs
 slave-4: <IP_ADDRESS>:2376
  └ Containers: 1
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 517.6 MiB
  └ Labels: executiondriver=native-0.2, kernelversion=4.1.12-boot2docker, operatingsystem=Boot2Docker 1.9.0 (TCL 6.4); master : 16e4a2a - Tue Nov  3 19:49:22 UTC 2015, provider=virtualbox, storagedriver=aufs
CPUs: 5
Total Memory: 2.527 GiB
Name: 20a86d99da81

# docker-compose.yml
...
mariadb:
  image: nazarpc/webserver:mariadb
  environment:
    - SERVICE_NAME=mariadb
    - constraint:node==slave-2
  volumes_from:
    - data
...

$ docker-compose --x-networking scale mariadb=2
Creating and starting 2 ... error

ERROR: for 2  unable to find a node that satisfies node==slave-2

Similar results with constraint:container!=*mariadb* and any other constraints/affinities:(
Ubuntu 16.04 x64, Kernel 4.3.0, latest versions of Engine, Compose, Machine, Swarm

Hi @bergtwvd - what kind of volume dependency do you have?

I use:
-- volumes-from

@bergtwvd You must add the node constraint on the ge-settings container

@bergtwvd I am hoping your question was resolved. If not, please reopen.