mailin

Good day. I need to use a server to receive emails from mailin and then the emails get posted to the server. I am quite new to the MEAN.js as soon as I post the email to the server I receive error 401 not authorised.
How do I add an exception to the routes to allow this without making security issues?
http://mailin.io/doc

I solved this issue by removing the
incomingEmails.hasAuthorization
object from the routes.


Top-level await now stage 3

Top-level await is now stage 3 and the globalAwait option should be removed and the next option should be used instead.
@fkleuver You add this to your TODO list?

Thanks for this issue. This repository and project will no longer be maintained, please consider its successor: https://github.com/meriyah/meriyah
Thanks for understanding and we apologize for any inconvenience!


Why is there no headEulerAngleX available in Face detection?

In flutter, there seems to be no headEulerAngleX parameter available. Why?

It seems that they forgot to add it on the library, but I was able to get it. It's pretty easy, if I have time I will create a Pull Request.
Just find in every file of this package where headEulerAngleY is used, and add headEulerAngleX:

Closing as resolved. That is included in the latest version:
https://github.com/bharat-biradar/Google-Ml-Kit-plugin/blob/master/packages/google_mlkit_face_detection/lib/src/face_detector.dart#L131-L159


Made sierra contracts be felt-vec based.

Stack:

#1485
#1484
#1482 ⬅

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.

This change is

crates/starknet/src/contract_class_test.rs line 19 at r1 (raw file):
Previously, orizi wrote…
in here specifically - this would not make sense - as this is only the debug info, which will be used for debug only, so it cannot be here within the serialized program.

I see, but I find it strange that a sierra can be serialized to felts only inside a StarkNet Contract.


SW 5314 Added project deliverables views for search

Added project deliverables views for search
Created ProjectDeliverableView and search table for it

#1940  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @tommylau523 and the rest of your teammates on  Graphite

Merge activity

May 8, 2:21 PM EDT: @tommylau523 merged this pull request with Graphite.


download-manifest command returns 404

End user reports that he gets a 404 when trying to do a download-manifest from a manifest file created from the UI for the Immune Cell Atlas data set.
Reproducible for me on hca 5.2.0, Python 3.6.4
Zenhub ticket #125  -- this from the end user
I followed your link, and I was able to download the manifest file. And then, I just tried to download the entire project (BM1 to BM8) using CLI, but got a bunch of errors:
$ hca dss download-manifest --manifest hca-manifest-357ed11f-6006-46c2-b8d8-7760acba3dc5.tsv --replica aws

Traceback (most recent call last):
  File "/var/task/chalicelib/dss/error.py", line 59, in wrapper
    return func(*args, **kwargs)
  File "/var/task/chalicelib/dss/api/bundles/__init__.py", line 49, in get
    raise DSSException(404, "not_found", "Cannot find bundle!")
dss.error.DSSException

I looked at the manifest file, especially the first and second chttps://app.zenhub.com/files/93565055/139c0c1d-13e5-421b-8107-6a9e62bbd3c8/downloadolumn, and I'm not sure what I'm seeing is actually right. As shown below, two UUIDs are concatenated with double vertical bars (looks like "or" operator to me, but anyway). Same for the bundle_version column:
bundle_uuid
0bbb26b9-8c8f-444a-989e-1981d8e1fd09 || 4dbed2a8-3755-47ff-9808-d602ae4985f9
bundle_version
2018-11-29T153103.948395Z || 2018-12-13T000432.880404Z

I verified that the manifest file in the current deployment of prod created a piped entry as above for each fastq file, and that a truncated manifest file failed immediately on download. (attached)
INFO:hca:Downloading bundle 72a60bff-a727-4c86-b6f0-938d02701f2e || cc5cb847-caf5-4135-a274-d203032877de version 2018-11-29T153131.476016Z || 2018-12-13T000102.935762Z ...
WARNING:hca:Bundle 72a60bff-a727-4c86-b6f0-938d02701f2e || cc5cb847-caf5-4135-a274-d203032877de failed to download
Traceback (most recent call last):
  File "/Users/kosborn/Documents/dev/hca/py364/lib/python3.6/site-packages/hca/dss/__init__.py", line 479, in _download_manifest_tasks
    min_delay_seconds=min_delay_seconds):
  File "/Users/kosborn/Documents/dev/hca/py364/lib/python3.6/site-packages/hca/dss/__init__.py", line 151, in _download_tasks
    bundle = self.get_bundle(uuid=bundle_uuid, replica=replica, version=version if version else None)["bundle"]
  File "/Users/kosborn/Documents/dev/hca/py364/lib/python3.6/site-packages/hca/util/__init__.py", line 207, in __call__
    return self._consume_response(self._request(kwargs))
  File "/Users/kosborn/Documents/dev/hca/py364/lib/python3.6/site-packages/hca/util/__init__.py", line 195, in _request
    raise SwaggerAPIException(response=res)
hca.util.exceptions.SwaggerAPIException: not_found: Cannot find bundle! (HTTP 404). Details:
Traceback (most recent call last):
  File "/var/task/chalicelib/dss/error.py", line 59, in wrapper
    return func(*args, **kwargs)
  File "/var/task/chalicelib/dss/api/bundles/__init__.py", line 54, in get
    raise DSSException(404, "not_found", "Cannot find bundle!")
dss.error.DSSException

Traceback (most recent call last):
  File "/Users/kosborn/Documents/dev/hca/py364/bin/hca", line 11, in <module>
    sys.exit(main())
  File "/Users/kosborn/Documents/dev/hca/py364/lib/python3.6/site-packages/hca/cli.py", line 136, in main
    result = parsed_args.entry_point(parsed_args)
  File "/Users/kosborn/Documents/dev/hca/py364/lib/python3.6/site-packages/hca/util/__init__.py", line 551, in arg_forwarder
    return command(**command_args)
  File "/Users/kosborn/Documents/dev/hca/py364/lib/python3.6/site-packages/hca/dss/__init__.py", line 453, in download_manifest
    raise RuntimeError(bundle_error_str + (' and ' if bundle_errors and file_errors else '') + file_error_str)
RuntimeError: 1 bundle(s) failed to download

Thanks for finding this. The easiest workarount for now is just to use the _v2 download (soon to become configurable via a --layout option in #317

Is this related to databiosphere/azul#955?

@theathorn yes, from my understanding  DataBiosphere/azul#955 will fix this.

As @jessebrennan points out, #955 will ultimately fix this. However I think the CLI—or even better the DSS—should validate the syntax of the bundle reference (UUID and version). The status code returned by the DSS should not be 404 but rather 400 due to invalid syntax of bundle UUID and version. I'd prefer the DSS to do that, rather than baking in an assumption of what constitutes a valid version into the CLI.
Assigning to @kozbo for triage.

Closing this issue, and opening one for the 404 return.

The fix will appear in production this week (hopefully, Wed). Updating the CLI is not necessary to get the fix.


Improve integer precision to uint64 as ovs does.

We want to generate interface metrics from interface statistics and found that integer precision in libovsdb and ovs does not match.
https://www.openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.html

   Statistics:
     Statistics: Successful transmit and receive counters:
        statistics : rx_packets  optional integer
        statistics : rx_bytes    optional integer
        statistics : tx_packets  optional integer
        statistics : tx_bytes    optional integer
     Statistics: Receive errors:
        statistics : rx_dropped  optional integer
        statistics : rx_frame_err
                                 optional integer
        statistics : rx_over_err optional integer
        statistics : rx_crc_err  optional integer
        statistics : rx_errors   optional integer
     Statistics: Transmit errors:
        statistics : tx_dropped  optional integer
        statistics : collisions  optional integer
        statistics : tx_errors   optional integer

https://github.com/openvswitch/ovs/blob/d29491eeb4a6e2128430eeac9a08327d8e7d8ed6/lib/netdev-linux.c#L201-L227
struct rtnl_link_stats64 {
    uint64_t rx_packets;
    uint64_t tx_packets;
    uint64_t rx_bytes;
    uint64_t tx_bytes;
    uint64_t rx_errors;
    uint64_t tx_errors;
    uint64_t rx_dropped;
    uint64_t tx_dropped;
    uint64_t multicast;
    uint64_t collisions;

    uint64_t rx_length_errors;
    uint64_t rx_over_errors;
    uint64_t rx_crc_errors;
    uint64_t rx_frame_errors;
    uint64_t rx_fifo_errors;
    uint64_t rx_missed_errors;

    uint64_t tx_aborted_errors;
    uint64_t tx_carrier_errors;
    uint64_t tx_fifo_errors;
    uint64_t tx_heartbeat_errors;
    uint64_t tx_window_errors;

    uint64_t rx_compressed;
    uint64_t tx_compressed;
};

Case
=== RUN   TestOvsToNativeAndNativeToOvs/Big_Integers
    bindings_test.go:447:
        	Error Trace:	libovsdb/ovsdb/bindings_test.go:447
        	Error:      	Not equal:
        	            	expected: uint64(0xffffffffffffffff)
        	            	actual  : int(-1)
        	Test:       	TestOvsToNativeAndNativeToOvs/Big_Integers
        	Messages:   	fail to convert ovs2native. input:<PHONE_NUMBER>3709551615(uint64). expected<PHONE_NUMBER>3709551615(uint64). got -1 (int)
    --- FAIL: TestOvsToNativeAndNativeToOvs/Big_Integers (0.00s)

Expected :uint64(0xffffffffffffffff)
Actual   :int(-1)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

3 of 5 (60.0%)  changed or added relevant lines in 3 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.02%) to 74.91%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

modelgen/table.go
1
2
50.0%

ovsdb/serverdb/database.go
1
2
50.0%

Files with Coverage Reduction
New Missed Lines
%

client/client.go
1
71.32%

Totals

Change from base Build<PHONE_NUMBER>:
-0.02%

Covered Lines:
4986

Relevant Lines:
6656

💛  - Coveralls

@halfcrazy I don't think this is quite the right way to do it.
First ovsdb protocol (RFC7047) defines  as a 64-bit value A JSON number with an integer value, within the range -(2**63)...+(2**63)-1. and on x86_64 (and I presume ARM64) golang's int is 64-bit so it should be sufficient. But you can certainly argue that the modelgen should use int64 instead of plain int.
Second the OVS vswitchd Port statistics are also defined to be  via ovsdb so we can't just switch those to uint64 either; they have to stay int64 and we just have to accept that there's a sign mismatch there...

i get it


Fix File Permissions of powershell-bin

The current .tar.gz files in the PowerShell GitHub releases seem to have the pwsh file set to mode 644 now - effectively making the file not executable.
Changes in this PR will make pwsh explicitly executable by changing the file mode to 755 after copying the archive contents.

Thanks for notifying me! I've published a new pkgver, see 7cb063f6d887337b648f49718c55b81c8a6be793.
Closing the PR as this repository only mirrors the AUR package repositories.

Awesome, thank you so much! 😄


Respect AVATAR_EXPOSE_USERNAMES for img alt

This will prevent scraping "alts" for valid site usernames.
Submitted for https://github.com/grantmcconnaughey/django-avatar/issues/188

Coverage increased (+0.2%) to 84.783% when pulling 46781441e2f0dfa2b0786a65e6873ae510e840eb on patrickscottbest:django-avatar-patch-188 into 3f4a8d284efe1c2d4c8babb4f668e67aa7f4d5df on grantmcconnaughey:master.


New find_duplicates component

Use case:
I have a dataset that I expect to be distinct on a number of columns. But it is not. I want to look at all of the non distinct or duplicate records to find out why they are not distinct.

Proposed new component find_duplicates or find_non_distinct.
Takes a table and a vector of columnsto find the duplicates on. Returns all records that have duplicates across the selected columns.
Table.find_duplicates self group_by =
any3 = self.aggregate group_by [(Aggregate_Column.Count 'InternalCount')]
any4 = any3.filter 'InternalCount' (Filter_Condition.Not_Equal 1)
table4 = self.join any4 Join_Kind.Inner group_by
any6 = table4.remove_columns ['InternalCount']
any6

I think the signature should be a mirror of distinct:
    duplicates : Vector (Integer | Text | Regex) | Text | Integer | Regex -> Case_Sensitivity -> Boolean -> Problem_Behavior -> Table ! No_Output_Columns | Missing_Input_Columns | No_Input_Columns_Selected | Floating_Point_Equality
    duplicates self (columns = self.column_names) case_sensitivity=Case_Sensitivity.Default error_on_missing_columns=True on_problems=Report_Warning =


⚠ ClamAV has degraded performance

In d962494, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 54 ms

Resolved: ClamAV performance has improved in a8fd792.


Fix to Avoid Printing Threshold for Regression Models

Regression Threshold Fix
Part of this PR addresses a bug in the return_metrics function where the threshold was being printed even for regression models. Since thresholds are only applicable to classification models, this behavior has been corrected.
Thresholds are inherently tied to classification tasks where predictions are compared against a cutoff value. Printing a threshold for regression models is not relevant and could confuse users. This fix aligns the function's behavior with its intended purpose, improving its usability.
The updated logic ensures that:

The threshold is printed only for classification models when print_threshold=True.
For regression models, a message indicating that thresholds are not applicable is displayed.

Changes Made:
if print_threshold:
    if self.model_type != "regression":
        print(f"Optimal threshold used: {threshold}")
    else:
        print("Thresholds are not applicable for regression models.")

Added Report Model Metrics Print to Binary Classification Output

Added print_results=True s/t report_model_metrics can output results when model_metrics=True

Added regression_test_kfold.py Example

Added a regression KFold example notebook to test KFold output wrt regression as well as the threshold bug fix.

I've tested this with the example scripts no errors. Regression works well and there is now a progression bar when calculating metrics.


SY flag is wrong

https://github.com/stijnvanouplines/blade-country-flags/blob/main/resources/svg/1x1-sy.svg

vs

https://en.wikipedia.org/wiki/Flag_of_Syria

@nuernbergerA I fixed this, can you please check?


I can't generate with ocular a complete Graph ?

Hello,
I created a binary CPG from Jar file and I loaded it in ocular
ocular> loadCpg("log4j.bin.zip")
And then I export it in JSON format:
ocular> cpg.method.toJson |> "/tmp/log4j.json"
The JSON Format is not the one I need, because it's not full, there is only methods.. . I need I full graph representation with alls nodes and edges etc.. The format sould by like this file base.json
So how can I do ? there a command to execue in ocular ?
Thanks in advance for your help.

Hi @omah69
You should be able to generate a complete CPG in JSON format using:
cpg.all.toJson

Please feel free to re-open the issue if this doesn't solve your problem.


bigquery: rename TableReference.dataset_ref

Rename to dataset to be consistent with Client.dataset. Both
methods actually return a DatasetReference.

@jba LGTM modulo the missing test changes (The unit tests for the property also need to be updated, I'm assuming you've seen the CI failure)

I imagine there are unit tests to update too?


api client using rest-client gem

I know it seems like im spinning my wheels with all the api prs... but it would be much better to use rest-client for the rest client functionality than Net::HTTP. I tried to do this originally and was having a hard time requiring the gem in a library. I got it working with:

chef_gem install of rest-client at compile time
build-essentials default recipe at compile time
only require 'rest-client' in the library after the gem has been installed (nested the require inside a method in the library)
add gems to be available to rspec on the test-kitchen instance using Busser::RubyGems.install_gem('rest-client', '~> 2.0')

Im gonna replace most of the http functionality I hacked together with rest-client builtin functionality.

[x] delete old Net::HTTP based library, specs, kitchen tests
[x] create new rest-client based library with all functionality from previous api client

[x] specs
[x] kitchen tests

I didn't include as many specs to be picked up by chefspec this time, but the functionality is all tested by test-kitchen so I'm not worried about that

not sure whats going on with that centos 7 test in travis, i just ran it locally with no problem

+1 looks good to me

this should be good now @pcross616 @ARentz07

👌

@pcross616 can we get this merged so i can finish up #133

+1


fix: pushTask is undefined during HotReloading

Hi, great library!
Can you please cover the case when during HotReloading throw this error

Fix in https://github.com/Zizzamia/perfume.js/commit/2668d3428d2fd76f3a588de03e3108a07706e33d
and
https://github.com/Zizzamia/perfume.js/commit/cba672ca4a1346a3fdfcf0628cf064731a67c2b0


Enhancement: Use a controller to render the form, success and failure pages

To implement the module at the moment you need to add a new page type which has a template that renders the form. You'd then also need to add a new page for success and error pages after submitting the form.
Since you have to add template code for this anyway, it would be nice if a controller with three separate actions (and templates) could be used instead so I just need to modify the templates to create the form and the success/error pages.

It is already using the Controller, but just via an extension. On the latest feature/updates branch, I've added the shortcode (although that's an iffy one, as the form is wrapped in a  tag, which isn't allowed)
I guess an example page type and defaults for that would be a fair backup? I don't want to enforce new PageTypes, as the reason I went initially with using an Extension, was I expected it to be used in a Sidebar or Footer.

Updated to have a functional controller in SS3 and SS4. Example templates can be found in the templates folder.


Feat/display all current leagues

Fetch all current leagues
Downside: there are too many requests and not all leagues infos are fetched

There seems to be an issue with the league logos. Sometimes there's no source for the image and sometimes is not sized correctly.

There seems to be an issue with the league logos. Sometimes there's no source for the image and sometimes is not sized correctly.

The missing logos are due to errors: { rateLimit: 'Too many requests. You have exceeded the limit of requests per minute of your subscription.' },
As a workaround we can display the missing image placeholder, that the API returns for some of the logos anyway 🤷🏻♂

OK, let's do that.
As a separate solution, we can implement pagination/load more functionality and not fetch all league games at once.


Mentor profile api connection

Description of Changes
Connected mentor profile api in mentor profile page

Please could you optimize it for mobile devices??
My bad I forget to get it done.

@anmode just a gentle reminder to add level label to this pr.


SPARTN-1X-OCB-GLO bad decryption

Decryption of SPARTN-1X-OCB-GLO doesn't seem to be correct. The output result looks random (not a single field looks correct)
It looks to be related to the ambiguity resolution as SPARTN-1X-OCB-GLO are the only messages with 16 bits GNSS time tag defined in GLONASS epoch (rather than being 32 bits with no ambiguity or defined in GPS epoch)
Ideally a parameter of one of the function in the chain should specify if GPS time needs to be used or GLONASS
I'm not sure how to solve it cleanly for now but I'll think about it and try to come with a proposal (or maybe @semuadmin has an idea on how to do that properly)

def convert_timetag(timetag16: int, basedate: datetime = datetime.now()) -> int:
    ...
    ...
    base16 = datetime(basedate.year, basedate.month, basedate.day, 0, 0, 0)
    secs = timetag16
    if basedate.hour >= 12:
        secs += 43200
    time16 = base16 + timedelta(seconds=secs)
    return date2timetag(time16)

Code to reproduce :
import datetime

from pyspartn import SPARTNReader, SPARTNMessage

msgs = []

key = "930d847b779b126863c8b3b2766ae7cc"

# msgs.append(b's\x00\x14h\x04\x120[\x11\x08(\x18\x14&\x98\x9e|\xdaz\x14\x01\xc0\xa5HS\xbc\xdb\xba\xc7\xcd\x83VuQ\xa5O\xc6\xc8]G\xe8\xc6t\xbcX\xd79\xe1*6\xa9\xfe\xc2')
# msgs.append(b's\x00\x0e\xec\x10\x1d [\x1e\xc8\xd6_\xf6q\xb8\x94\xdfja\x7fLh\x94\x89#G9\xbd%\xdfi\x15B\xc6\xe6y\xb3V\t\x04D)')
msgs.append(
    b's\x02\xb8j\x18\xd7)+p[\x10\x88\x04\xcf\xe7\xb3\xec\xf2l\xc1\xd9J\xd2qj\xc4\x8fW[\\\x08\x87\xe4\xa0\xb1\x1c\xb3\x96\xfc\xdci\x07\xf2\xf5\'5\t\x7f\xd0.\xe42\x0c\x0b\xb8\xd9r|\x8b\xcf\xd8c\x02\xe8t~\xfayqJHVU\xb9D\x1b\x02\xe1\xedK\xb6%p\xf1Z\xc2y+$M\xf9\xad\xa1?\xcb\xde6\xc0\x99\x02)\x7f\xde\xb1\xc85\xc7\xab\xc0x\x9f(\xc3K\xe66\xa0c\\4d\xf6\xb0\xaf-\x10x\x06\xa7\xadGl4\xec\xe6_\xa5;\xde\x12\xb4_\xdd\x10\x83J\xfb\xf6!\xf5]\xeaR\x08\x06)\x9fg\x03${\x10\xefVR+\xa7d=\x8d\x97U\xe7\x88\xc7\x01&\xccD#j\x19d\x87\x92">\xcb\xdaOET\xbfL\xfc\x8bQ{\xca\xb9\x89\xae\xe0\xd6\x7f\xcf\x154\n\xe7\x87Bau\xb5\xf3&\xcb\x8dp\xbbi\xcck\x99\xf4\xdfq\xd5\xa4\x85U\xb8\xb0NE\x8eO\x1a\xc9\xf6\xf3\x95\xcc\xc7\xe0\xa5~\x97\r\xca\x954.\x0e\x0c5\xfc\x011\xdbc\x8d\x1e\x8d\x84>\x07\x0cL\x87\xc9\xec\xa5\xecBo\xce\xc13:\xcd\x83\x824~\xd05\xa3\xcaL\xb1M\xc3d\xba\xe0ob\xceC\xf3\xa8Vw\xaakJ\xd8dT\x83D\x03g\xad\x04\xb0s\x90!BJ\xa8zh!\xa5\xe1\xffiYb\xf3\x16\x18\xbd\xca,\xe8v\xff\xf6gLq\xeb\xbf\xe0\x02c\xf0\xa8\xf9\xd3\x11\x07\x9f\x1a\xc3\xd4\x867\x89\xf1\x0e\xe6\x99\xf3\x06\x87\x1e-m\xd4\x9a\xf1\xec\r\xf2\xb4P8')
msgs.append(
    b's\x02\x9d\xeb\x18\xd7)+p[\x11\x08P\xe3T\xd7\xbe5\xd9Q\x86\x95\xc2\xe3x\xbdK\x8aF)\xdf\xe7\xe3\xf7H\x076G\xab\xa9:\xa1\xc0\xd5;\xd2}t\xbc\x80\xe5\x88\xc0\xa7\xba7\xb93\xc0\xc7\xab\xfd,@\xe5\x9f\xff6\xae\xac\xe8-,U(\xdf[\xe4\x0c\xa3d%l\x8a\xdb\xfd\xa2e\xc1\xbeR\x1c\xa2\x10\x01\rNJ\xd4-Z\x17}\xf2O\xf6\xb4\x1fH\xf3\xd2T\x12\xe2W\x13\x12@\xdf\x8a\x16\x85S\x10{{\x97\xbej$\xb5@\x98\xd3\xaf\x90\xee\xe2.\xef\x82\x1c\xca\x9f\xf80\x9a(\xbe\xe2\x97\xcf\x85\xa8\x98\xccy{R.\xe1\x0fa\xdcX\x02\x80\x18\xe0\xc7\xd6\xd9s\xf6\t\x1b.T\xb0z\xaa\x82\x1d\xb2\x0bu\x1b\xd5\x04E\xb6\xaa\xe3\x1b\xbc\xc91\x9c\xa9\xd8\xefA\xa2Z\xf8\xe9T\xc1{\xa6\xf2Rz|1/;\xbd\xf2+\xf6Y\x10\xa6O\xcd\x8b\xe7\x13\xabO\xf4d\x05\x8e&\xe8\xdaQ\xd9\xban:p\xb8\xe9\x12\xe5":\x82\xf6v4\x8e\xf6?\x05\xd6\\Hf\x9d\x85\x04\x93L\x07\xde)\xa0\xaf\x06\'\xae*1\xc7\xbb\xdcoWL\x02\xed&\xf7\x94v\xcdZ\xa4>\xf5\x90%3\xdf\x13\xe8y\x14y\x9d\x7f\xe3G\x95\x84R\x0fa\xb6\xbeP\xe4U,\xd8A+\xef-\xa0A>\xea\xb5\xdaM')
msgs.append(
    b's\x02\x97\xee\x18\xd7)+p[\x11H\xef\x15K\xc1\\\x10\rQ\xaa@\x12\xea\xb59=\t\x03\xca\xf5\xd7\t\xae\n\xae\x9a.|<\x8b\xf3r"N\x18I\xc98\x01\x15\xfa\x0f\xb5\x91\xe7%Ph\t\x93\xb41\xe3\xcc\x89\xf6\xcb\x9a\xe2\xb9|\x82?%$\x06\xe6\xfc\xfd\n\xd7\xdd\\\xdapV\xf5\xc8\x8a\x8a-0\xb4\xf5\x8d;\xbd\xcf7\xa8.3\x1aTe\xdc\xf9\xa9\xee!3Z\xe8X\x106\xebw\\J;\xf1\xdd;\x9c\x14"\xf1mj\xf9\xc4Nkpb&\x1f\x15\xb9\x1a|\xd3u\xf9\x1e\xa0\x8cq\x0c/\xe4\xa8\xfd\x10\xa8DQ\xfcTOU8j\xeeq\x15\xf6\x84w\x1c\x9f\xa2H\x84:\x88c#~p\xf03&\x0e\xdd5$\x98\xce&(\xd4\xd1@M\x83i\xe9\xd9\x9a\xaf\xca;K\xbe\xc5ZDAO\xe3\x02Q)\xd2/\xff\x06\xe2v!\x17\x9a\x00\xffW\x03\xcaV\xfe\x03kCA`\x05\xf1"\xb3X/%\xc6\x8cI\xbd\x91:\xd3ht1\x00^\x1d6}\xd1\x8e\xcbE\xb4\xce\xf1\xdeq,\x97<fT\xe25n\xce@\t\xd1\xd5m>I\x82xU\x82\x1b\xa6\xc3\x07\x82jm\x80p_\x10\x06\xc4EupT\x86cIk\x0b\x16\xf3h\xc6\xc0\xb6\xe0D')
msgs.append(
    b's\x02\xabj8\xd7\'\xda\x10[\x1f\xc8\xd1\x07\xfb\xde\x1a\x08\x90\\{\x7f;\xa1\xe5+2@y{\x89\xca\xad\x8a\x9f\x8fu\x8ahrCm\xae\xdb\xbdh\xac\x9a/\xfcb\x8eH\xcdE\xf1\x17#\xd1E&\x17\x87\xb5\x06\xcb\xddW\xea(\xbe\x19c\x0f`\xf7%\x82\xdf\x84\x8f\xbb<\xdb\xf1\xbeV\x86)\r\x95\x08\xe6\x12|\x83_\xea\xe7\x04$\x18\x86\x0f\x83\xef\x1f\xcc`V\x8a-\xe8\xdd\xf9\xceW\x1f\xc2\xc4"\x8c;\xf6;\xb5\xbf\xe3G(\xd4\xc5kT\x8f\xdb\xb1\xfap\xa0\xd3\xe3\xb2[ \x8a\x7f*\r\xc3\x05\xa4\x80)A\x05\xd1^\xd6\x87\x9e\x86\xfcH\xce\xa5\xd5\xbe{4\xa9\xaa?G\xdc\xc8\x89c2s\xccR\x90\xc2<\xf3\xf2\x13\xb0\xdc%>q\xc38\xf3 \xd4}\xfcST\xb8\xa9\xbb\xd2\x0fw\x156-5\x11#\xc3\xac\xf9\xe4\xf4\xe4\xdbU\x13\xb7\xc5\xdc\x9b\xca\xf3\xee\x0b!\x9aI\x1bP}\xc2\xcd+\x9b\x96{\x91\xcbL\x84T\xdb\t,\xcf\xa7\x9f\x93\x9b\x8d\x93\xb99\xbb\xd2\\;\xb5x\xc7\x9f%F\x95wzX\x01\x1d\x80\x15\xe0|Ix%\xe8\x90\xe3ps\x1f\x8e\x90+\xa5\xbfXB(\x85\xde\xb1\xffY\xe0N\xc2~\xb1\x01\xed\xd2\xe6\x00\x9c]\x9f%\x84\xcbB\xbf\x89\xb4\xda\x8b\xf6/\xaa\t\xc5\xb5\xe2&\x1e\xcdk\xe2r\x11\xf0\x0cz\x9b\xa9v\x99\xe0~\x8d\xf5W\xde\xcf\n\xac{\x88\x0e')
msgs.append(
    b's\x02\xc8\xee8\xd7\'\xda\x10[\x10\x08<uA)]O\xe24\x95\xbd)\x05\x9e)\x02M\x16\xb2\xdd\xbe\x1c\xce\x15\x0b\x03\xc2\xb1\x8e"\xcd\xd1\xce0\x8di}\xc5$\x8ezd\xc6\x83]QO\xbf\xf44\x95\nv\xb0\x16\xec\xc1\xc3\xc0\x9d\x95\xdc\x9cR\x07l\xda\xc8\x05{\x18|\x11\x81\xdc\x1c\x84\x14\x91\x87\xba\xbc\x05L\xa4\xaa\xed\x8d\rsfqOh\xd7\x17b\x92w\x13\x959\x9cT\x8d\xd7\x0f\xd4\xb0/\x8a\xcfH\xe9\xce\xd0\xd3\x0e\x85R\xb9N7\x18Q\xddK\xb2z\xe5\xc5\xef\x82\x06\x9b\x94\x0c\xa8Sl\xe6\xb0QN\xe7\xd0Y\xab\x8f\x03\xa9n \r\x0f`\xe3\xfd*\xcbN\xe3\x08\x08\x0c\xb5\xb7h:\x06\xe1\x98\xc6At\xdah\xcd\xd7JC\xe9\x0f\xca\xd8\x96\xcc\xd08\xdb\xabw\xa4\xa7+c\xff\x8b\x056\x98\xf1\xca\x19l\x04V!p\xe2\xf3K\xaf\xe2b\xae\x9f\xd3@\xcc\x8fM"n\xc6_9\xdf\x01\ta\xba3\xf1G\x17?\xbd\x8d\xc0\xf6\xb4#\xccRe\x8e<\x1c\xa8\xcc\x02\x11\x89\x18Z\xdd\xca\xdcms\x82\xbak\xf3P\x08y\x12a\xd2$\x9cn\xc2*6/\xc6(Ksc\xaf1\xb8k\xb9\'\xd0\x84\xee\x1b\x82^\xcdG\x10\xf1\xe8\xe5\xb8\x88\x81\xe7y\xbfZ\xa9\xb9"\xf1LpL\xb2\x06\xf9\x95O\xef\xf63\xe19\xb9\xe9\xa2\xe5\xba\xa7\xd7j\xbd\xdf1y_\xbe\xcc+\x936\x94;U"\x81\xac\x83_\xd7\x8b\xb9\xdb\x1e\x06\xbd\xcf\xd5pz\x8cS\xcb\xcb\xf1\x96\x04\xf5jUJ\xc9G\x83\xf6\xces\xc7\xad\xf1=\x00\xbe\x91\x134\xa9\xf3\x07M\x1d@aUPJ5z\x06\x9e\xcdv%')
msgs.append(
    b"s\x02\xce\xed8\xd7'\xda\x10[\x10\x88'\xe1\t\x8b\xdbq\x0c/\xc7\x88`\xd5\xe3\xb5\x90(C\xc3\xd9\xc2/:\xaa\x81\xd187i\xa5}\x03\xfe\x1e\xb6'\x15{c\xbdLr\x8b)\x1d[\xf4\x1fu\xce\xf3\xdc\xe3%\x00v\xc7\xc5\x986\xc9l\xd6\xe7\xec\x8e\xa5\x8f=\x89\xf1[C\xa9,B\x12\x97\xe7\xc4\xady\x13M\xc5XI\x8fV\xf3\x7f\xee:u\x1d}ORN\x97\x80\xb7\xcap\tgr\x06\xa7\xfc/NE6\x816\xd5\xb74.\r\x92\xb1\x8e\xf1n\xca\xa3$\xab\xee\x11\xec\n\xcc\x1d\x8f\xe6\x1d\x1b\xbe\xd97CQ\xca\xf7\xf78\xa0\xb5\x91\xfe\xa0\xdbv(@\x15A\x88\xe6\x92\xc3\xd4\x80\xbc\xd0sv\xf2P\x8a*:'\xc1\xa0'\xde\xed\xdb\nl\xcdm\x0f\x97\x15Z\xd3X[\xdd\x05\xe8Q\x96\x01q\xdb\xd1\x8cgI\xe1~5Y\xd8\x82\x9b#\xaa\xe6\xe9\x01\xf9\x0f\x15f)\xee\x03_s\xdb\xdeWh\xa9;\xbeC\xf4\xa2\xb5U\xe9\xf5\r\x1f,q\x8co\x9a\xef\x7f\xc9\x8e\xf7\xbe\xb6Rg\xe3\x99\xa3J\xf8.\x94]U\x9d\x1f\xa9F:\x93\xca\xce)\x92hF\xa9[!\x08\xf6\xce\xdfO`\xfe'\xad5\xa33\xda\x8aq\x80\x92\xdb\x06r\xc4S:\r\x13d$\xa8\x1e\xc8b\xbb\xed\xd9\xfaC\xb3\xee\xc0~<\xaa\x044Q\xca!>\xfe>\x84E\x8a\xf4*\x19\xb9X\xe9\x9c\x1b{\x95\x13\x1b$v\x045hy21\xa8D\x06\x9f7\x7f\xbf\x1b\x95\xd8\xea]-\xc7mM[\x85*\x10\xfc\xff\x1d\x87s\x82k\x92\xf02\xb6\xd0\xb7\xe5\xe4*\x92\xb1R\x90\xb4\xc3\x07\r\xda-$\xe2\xd4:\xe7\x95\x03\x02\x16/\x82o\x8ag\xc6\xdbz\xe8")
msgs.append(b"s\x02'`8\xd7'\xda\x10[\x10\xc8\xb8\xf0\x1b\xe6\xba\xc9:\x1a\xb6{\xae$cf\\k3\xed\xec\xac\xc4T\xad{\xbe:/7\x0b\x89zHa\x14\x91\xdfJ\xc3(\\\xad\x14\xc5I\x9d|\x8c\xc6\xd1\x97\x0fW\xd34\xa7\xf8\xcb\x1a\x1c\x0c6wT7:g\xfdineJ\x18\xb0\x8c\xb3\x96\x92u$\xf3\xd9")
msgs.append(
    b's\x02\xeb\xe5(\xd7\'\xda\x80[\x10\x08\x84\xc4\xf4\xb5r\x17\xb9e\x82\x9c#J\xe7|;\xce;NZ\x93\xf3\x80\x9c\xc7s\x1dG\xdc\xde\xfc\x92j\xe4-R\xb7\xcb\xac\x14\xff\x04`_xI\xdd\xb72\x06SC{c\x9e_R\x8e\x17\xfa\xf3r\x0b.\x9aC\xffr\x8dJ)\xeb\xb0Ik\x8d\xe5:\x8dU\xb7\x8f\xe4\x99\xeeD*\xc4\xf5\xbd\xb7-\xa4B\x11TV\x93%\xf3\xd9\xecLw\xca\xb7f\x8e\xe5\x1dq\xd8\xaeIY\xde\xeeRO\xd4\xb5\x86\xa7\x18\xe6 \xee\x9c\xb5&\xeee\xbb\xeb1\xa5\xadJ\x93\xbah \xbe\x92\xfc\xfa\xeb\xa0X\xa7\x89\x81\xe9\xbeJ\x91\xfa8j\xa4\xb6\xc2\xb0\xed\xban)L\xd3\x96\xe9 2?&\xe9w\x11\x8e;\xeb]<FX*\xc5D{\xb4\xc1p\xaf\tE\xbd\x19\xa4) \x9d[\t6\xc1`\xfa=T\xeeo\xd3Q\xdet\xecs\x9c|e\xa5\xdc\xe7Qx\xb4S\xb9\x0fU\xfaS\xb3\x0c\xdf\xe0\x04\xf7\x89<"\xd2\xb8\xcc\x0b\xa5\xbb\xa0\xa21T\x88\x1d\x07h\x01\x15\xbb\xe7<\xee{F\xb3t\xed\x06\xd1\xe5\x9c\xb8\xba_\xb0uZ\xca\xd3\x91"\xc0mB-\xff\x18\xde\xda$\xe7\xc1LX*\xe0.\xf6\x91@\xfd\x8cCx\xed\x87\x0e\xa7{\xf5[g\x15<\xd8\xd9j\xfd\x967\xf0\x83\xe7Y#C2\xde\xb4\xe1\x06\x16\xf3\x94!\xf9:\x12S\xb0\xae\xdf-\x01U\x0e\xf8\xc8\xae\xae\xec\xeaT\xc4\xf3[\x11\x00l\x1e\x95\xaf\x00\x81\x7f\xda\xee\x08\xcdLw[\xe6TLe\xa2\xff\x08\r\x91(\xfcf\x9d\xc6<\xc29\xc6\x83\xb3tB\x95R\xf3\xe5\x89\xc4\x9d\x8e\x99\x1cj^\xa8\xc1\xe0x1=\x01\x14\xf1\x88\xcaOr\x05e\xb1\xc2\xd3\x0em\x7f\xc2\x15\xeb\x05\r\xc5\xa8\xff\xa9W~\xf1q\x1f\xe7\n\x1aB\xc1\xeb\xfd\x98xF=\xe9\xde\xdd\xd9\xc0\xdf\'\xd3\x03\x81\xbc\x97\xf4` \x03KQ\xaa\xe2\xc2\xb5^\xa3')
msgs.append(
    b's\x02\xee\xee(\xd7\'\xda\x80[\x10H{\x1e$z\x86\xee\xae\xfd\x97f\xef\xefa\xbeX\xb0\x0f\xde\xfa\x97\x1d\xe8$\x8c\x08\xe6\xf1m\x14\xd6#S\x19\xea\x1b\xd9\xee/\x15\xa1^\xc4t\x8c\x1d\xcca\x18Zq,\xb8\x0e\x90\xe1[\x96\x1b\xd1\x16\x87\xb7\x9f(\xf28\x83\x17x<\x16\xf8\x13T\xda\xa1\xec\xde"\xfe~\'\x1ap\xbb\x1c{\xf0\x88\xe8\xe1V\xf5\xfd\xc1\x8a|\xc4\x0e\xf3s\x17z\xa7\xbd\xd8w\x9f\xca\xce\xbc\xb3\x97w\xa0\xd0+\x0e9J&/~9\x9f\xdeT\x9d\xcf\x17\x99]\x177L\xf2\xadO\xd6\xf1M\xf7Wv\xcc\xdfK\tX\xaf\xe0X\xff\xa1\xb5y\xd9/4\xde8\xe4\x90}\x08Z\xa4\x0cAr\xa8\xd5\x82G#7\x85\x83V\xbd\x8f\xef]\\\xb6&6\xeer\xc8{h\xea<\x9e\xaaFc\xa6\xcdx\x84\xbfU\xa1l\x7f-n\xcf\x10P2H^\xba?\x97S\xd3LT\xfc\xb0\x05\xae[\xf9\x9d\x17\x0b\xa5\xe6E?2_fr\x14\xc22\xe2?I\x18\xbc\x92\x9c\xc1\xe8\x93i\xef\xb4\x95%U\x1d:9\xb5\xd5\xb4U\xd2\x1b\xb5\x89\x9e\xd2\xe8\x1d\x05\xaaa\x84\xc5\x12\xd5\x04\xf9\xb4\xbe\xe1g\xe1a\xc8\x96}\x89x\x00\xc2\x90u\x0b\xe4\x02\xc9\x0110\xf6\x08\xf0\x8bw3\xb1\x8ckU\x82&)"p")l\tZLci\xae\x08\xd0\x12\xe0\xe1#W^P8\xa0\xf4\x84\x06lbH\x07bX1\xf0\xcda1/\xc0?\xa2\xb0-\xe3\xfd\xed\x01\xb15Z\\\x97\xea\x1f\x8a\x9d\x08\xa8wO"\x95\xfdJ\xbb}EC\x0c\x99\xf1\xf3\xfa\xbe,1\xf2\xd8\x01Rf/\xa2\xf5x\x8e\x90\xc8B?\x15\xe7\x95\xe6\x1b?\x10\xc4\xdb\x01f\xf6t\x03\xc2\x1a\xb5\xf6CX\xfa\xc0A\xfe\xc47-\xe86\xeb\x9b\xe1\xb9\xa7\xf4\xf0\xcd\x91\x86\xf3\x1c\xb9\x9a\xde\x0b<\xce\x02\x12\x13\x8e\xddV\xa1_\xe4\xcc\xb9\t\xb6\x7f\x01\x83|\xf4\xc6\xb8uso\xa8\x05K\x08')
msgs.append(b"s\x02+\xef(\xd7'\xda\x80[\x11\x08N(pwa\x85\xab\x9a90y\xf6+3\x88C\xb8\x97^|\xba\xdb5\xa1\xba\x81\xb6$Z\x94\xd6\xdfE\r>8\xc7\xd2U:\x1b}z\xb9|$\xd7\x8bs>I\x01i\xe4\x8eL}\x06\xe8\x99\xff\xc0h\xd5\xee\xc6\xb7\xeaAb{\x13\x8dc\xa0N\x1c\x05\x8f\x08a?\xa9g9i(\t\xc5&")
msgs.append(
    b"s\x00}\xe9\x08\xd7'\xda\x80[\x11\x88\x97\xfa%m\xeb\r\x9evnH<\xe0\xca\xa9a@\xef\xb8\xd9E\xd4\xban\xd5\xd5\x9b\xce\xe8\x11\xf0&2\x83A\x0e\x8aR\x14)\x14\xe8R\xa8+\xa4\xe3\x05B+\xc5\xe3\xd6/\x13\x84\xb7!\x98\xaecu\xb2j!kq\x82\xb6\xf2I\xec\xfc\xca\x9b\xb1\x8e\xf8\xc6\xbeC`\xe0\xa8p`Qg\xa2\x01Q\xfb\xbb\x8d\xdf\xa6\x9e\xa2i1m\x15XD\xbd\xb7\x87\x0en\xa8\xaa|\t\ro\xe6\x18  \x8a\xafQ\xd1\xeb\x9erJ\x98\x07#\x11\xa1\xec\xdd\x10\x00#^\xb3WRz\x86\x9c`IL\xaa(\x1b\x9c;Z\xa4\xb4P\x9f\x0c\xe5\xb2\xa4\xb4\x9c\xce\xb2@\x9aO\xf7OM\xc4&>&-5\xf3:\xcf\xbbuA\x044\x98\xeb\x85\xd7\x95\xcb\x1di\x9ci]\xb3K\xbd\xc5\xfb\x9fLQ\x1a~\xe9^\xf5{\xf3\xb2\xa39'\x96!\xachE\xdd\xfa!\xea\xea)z\xd4p_\xed\xa8k\xf3L\x1b\xc8\x8fZ,\x91\x86\xaa\x18f\xd4U\x8cLD\x8a\xa7-\xaa\xbc")
msgs.append(b's\x00B\xec\x18\xd7)+p[\x1fH0\xb6\xb6`j\xef\xa5\x03\xb3\x1a\x1cd\xbc\x17\xa7\xf5\xb3\x95K\xfa)\xb2F\xc4\x9a:y\x867\xf5\x7fW\x96o\xbb|\x97\x81#\x8c\xef\x8ey\xd2\xfb\x89\xffF)1\xd3RA]\xe2\xe1\x17>\xf9\xfe\xf9\xa7XJ\xab[\xa6,\xb59\xd0W\xa1\x93\xa7H\x83Zb\xc3\x0b\xb5Y\xebtF5E:\xc6P\xd8\xccP\xfd\xfe:om\x9c\xf6p\x8a\xeb\x10]*/\xe7KU\xb76b\x97$\xf4\x8f^\xfb\xe8\xe4\xb2\xbdF\xf1\xbeH~\xa8\x9e\x1c\x81\xb1\x1d\xd7')
msgs.append(b's\x00Fg8\xd7\'\xda\x10[\x17HX\xfe\x1b|\xae\xf2\x18f\xd9\xaa\xfb\xaf0\xec\xf9\xabq\xcf*F\xed\x1e!\xd0^"(\xd3i<\xbbt\x1aU\xe0\xfez\xd4d\xfes\x00\x0eg#\x07\xed\x1f\xe2%\x9bb,B7&}\x98=F\xb4S\xb2\xccd\\\xe0Q\xd8Uc\xa29\x83K{\xaa%\xf4"\x00\x13U\xf6\xe3h\x10\xc2\xb7\xa0\t\x87\x9e\xce\x12\xf7\x1d}0d+4\x88\xaf;\x17\x95;\xd9\x8e\x94\xca\xf99\x898M,\xa2\xc9h\xd1\xa5\xf5spN\x1cc\x8aZx}\xa9X\x8c\xe4S\xe0\xe2f7\x97')
msgs.append(
    b"s\x00_\xeb(\xd7'\xda\x80[\x1fH\xa9\x81\xe5>2`~E\xa3O\xf7\x9b\x08R)Z\x96\xccI\xb0\xd0\xb4\xd4C\x8d\xcb\xcb\xadDx\x18\xcc\x94\xdbG\xce\x95\x8e\xef\xd9\xff\x1c\xef\xdd\xcf\xe8\xe7\x8fT\x80\xb5\x99\xc3\x10\x07=\x93\x82\xc9\xa4\x82\xbe)\xbc\xe6,\x16\x9e\xa5\xb4`N\x92\r2x1\x85\x82\x99M\xdd\x83\xec\xf3\xe8ov\x0c\xe5!\xcb\x85d\x8di\xe4Q\x1d\xcaE))\x871\x81\xc5\xbd\xbfc<\x0f\x82\xe0\x8b\x81\xd2\xc8T0\xfaz'\xdb\xf0\xc0\xa8\x8c\x13x\x93\x88$\x9c\xe7;\xfd\xa8\xe5t\xeb~Mc\x1aY\x80d\xcd_\xf1y\x94\xbd\xe5\xc6\xb6\xfd\x14i\xb6\x1e\xc0\x14\x96$]\xe1(\xe1\xb7v\x02$?\x9bd\xef\x8d\xc9\x12\xff\x99j3\x95U\xf5\x8e1p$\xa9\xd9")
msgs.append(b's\x00\x14h\x04\x12\xa8[\x11\xc8V\xf4^R\xac\xaf\xc7.Q\t\x82\x9c\xa3\xc2\x02H\xca\xb1J\xc4\x18\xc6A:\x90qZ-\x08\xee\xf8\xa8\x93\xc3\xfa\xcb\xdf\x9a\xa9\x0e\xaa\x9e\xf1')
msgs.append(b's\x00\x0e\xec\x10\x1d\x98[\x1f\x88r^\\\xff\xf6\x1a\xf8\x97\xf0)u"\xb1\x04\xe0\xb8\x1b\xbeu\x8d\xcao{\x01sUn\xc1\xc1b\x05I')
msgs.append(b"s\x00\x14h\x04\x12\xd0[\x12\x08&\x9b\nOi\x90\xe3\xccKp\x99\xc7w9\xd4\x8cY\xed'\xd2\xcb\x97`\xa4mT\xb5S\xbe&\xac-\x00u\x19\x1d\xcch\x96\x87\xcat\xcc")

msgs.append(b"s\x00\x0e\xec\x10\x1d\xc0[\x1f\xc8'e\x0f\xfc\xc4\x14z\x96\xc4h\x14\xe1\xec=\x05\x03\xc9\xa1h\xab\xc9\x99w\xbfN\x1fh\xee\xad\xb4\xf7\x1d")
msgs.append(b's\x00\x0c\xed4\x12`[\x17\xc8\x1c\\\x8d}\xf2\xafp=\xc9\x02\xf2J\xab\xa2\xd2Pc\x11\x00\r\xac\x16\xec\xd6\xd4j\x95?')
msgs.append(b"s\x00\x11c$\x12\xd0[\x1f\xc8\xd8O\x9e\x0f\x04X\xe7N7!\x9c\xa6g\x8c7\xbf[\t\x1c'\x99k\x954\xb8\xe8jR\x9dmBG\xd8\x07\x05\xd5K")

for msg in msgs:
    try:
        parsed = SPARTNReader.parse(msg, decode=True, key=key, basedate=datetime.datetime.utcfromtimestamp(1713519000))
        # print(parsed._decode)
        parsed_typed: SPARTNMessage = parsed
        print(f"{parsed_typed.identity}")
    except Exception as e:
        print(e)

Hi again @jonathanmuller
So - yes - if the decryption is incorrect the entire payload will be junk - there's no middle ground there!
Are you able to ascertain if this issue only affects SPARTN-1X-OCB-GLO messages with 16-bit timetags (timeTagtype = 0), or does it also affect other GNSS types (e.g. OCB-GPS or OCB-GAL) with 16-bit timetags?
Are you able to confirm whether SPARTN-1X-OCB-GLO messages with timeTagtype = 1 (32-bit timetag) are being decrypted correctly?
This is puzzling because, based on the SPARTN sources I've been using (Thingstream PointPerfect MQTT and NTRIP services), all SPARTN-1X-GAD (global area definition) messages have 16-bit timetags (timeTagtype = 0) but these are definitely being decrypted correctly provided I use the correct key and basedate.  I can verify this against exemplary output - see for example the gad_plot_map.png illustration. If I deliberately provide an invalid basedate, the GAD output is - as expected - gibberish.
The fact that GAD messags with timeTagtype = 0 are decrypted correctly suggests that the basic IV (Initialisation Vector) and decryption algorithms in pyspartn are working as expected as long as the key and basedate values are correct.
Unfortunately I don't have access to exemplary output for OCB or HPAC messages so it's must more difficult to ascertain whether they are in fact being decoded correctly. There's no explicit encryption validation CRC or hash, for example (understandably, as this is good cryptographic practice). One avenue I can use is to compare them with contemporary output from the Thingstream PointPerfect NTRIP service, which outputs unencrypted SPARTN messages (eaf=0).
Few suggestions just to discount any obvious hiccups (I'm sure you've checked these but just to confirm):

I'm assuming the key you're using is valid, but it might be worth double checking it hasn't expired.
What are using as the basedate? If a datetime value, what value are you using and how have you obtained that?
Have you tried using a 32-bit timetag from the same datastream in place of a datetime value as the basedate (pyspartn will accept either) - i.e. the gnssTimeTag value from a contemporaneous message with timeTagtype = 1 (maybe an HPAC message)?

In essence, can we discount the possibility that this is simply an issue of incorrect decryption parameters (key and basedate)?

I can confirm it's only SPARTN-1X-OCB-GLO messages.
In the same stream (60s of data), all HPAC, GAD and OCB messages are correctly decrypted, except the SPARTN-1X-OCB-GLO

Key looks valid as all other messages are decrypted correctly
I'm using basedate=datetime.datetime.utcfromtimestamp(1713519000))with this epoch being the time I started the mqtt client
I'll try that, but as all the other messages of the stream are correctly parsed I'm relatively confident the base time is correct
Yes, I'm using convert_timetag and copy/paste the messages for convenience

I'm relatively sure that's it's only a decryption problem for GLONASS ambiguity on 16 bits timestamp (for SPARTN-1X-OCB-GLO). I'll double check with HPAC-GLO decryption just to make sure.
Keeping you updated

I'll review the latest SPARTN protocol specification again to see if there's anything I may have missed with regard to special treatment for GLO 16-bit decryption, but as I recall it's fairly vague around the whole timetag ambiguity area. As I recall the IV and timetag conversion algorithms used by pyspartn were arrived at after lengthy discussions on the u-blox community forum.

I just tried with a fresh stream : datetime.datetime(2024, 4, 22, 7, 35, 0)
SPARTN-1X-OCB-GLO decryption worked without trouble ( I only launched the test on few minutes of data)
That leaves 2 main solution :

It always worked and my date time was not accurate enough and was right at the limit of the 16 bits overflow
As GLONASS time is relying on Moscov timezone (UTC+3) and not UTC+0, there is a 3h period around midday (and midnight) where the parsing is incorrect, and I was (un)lucky enough to record data in that time

I'll try again with a stream recorded few minutes before and after this critical time switch that is midday UTC+0

That seems to be it : to get a correct parsing (or at least what seems to be valid) of SPARTN-1X-OCB-GLO I need to set a datetime 3h in the future to account for conversion between GPS UTC+0 and Moscow UTC+3.
Obviously it works most of the day without trouble unless I record a stream between 12h and 15h. Just for completeness I'll try after 15h to see if parsing works again because the shift is "resolved".
There also seem to be a problem with datetime counting leap seconds while GPS doesn't, but as it's only 18s shift it's really hard to reproduce.
Let me know how I can help you and if you would like me to try open a PR for those 16 bits resolution ambiguity time shift.

That seems to be it : to get a correct parsing (or at least what seems to be valid) of SPARTN-1X-OCB-GLO I need to set a datetime 3h in the future to account for conversion between GPS UTC+0 and Moscow UTC+3. Obviously it works most of the day without trouble unless I record a stream between 12h and 15h. Just for completeness I'll try after 15h to see if parsing works again because the shift is "resolved".
There also seem to be a problem with datetime counting leap seconds while GPS doesn't, but as it's only 18s shift it's really hard to reproduce.
Let me know how I can help you and if you would like me to try open a PR for those 16 bits resolution ambiguity time shift.
EDIT : confirmed, parsing after 15h (UTC+0) works

I can't fault your logic, but this feels incredibly counter-intuitive to me. Should a comparable UTC+n adjustment apply to, say, BEI or QZS constellations based on their respective base timezones?
Out of interest, what specific criteria are you using to confirm that the HPAC or OCB payloads are in fact being decrypted correctly? Do you have exemplary data to validate the output against?
FYI This is the full extent of what the SPARTN 2.0.2 specification has to say on the issue of 16-bit timetag ambiguity...

... which gives absolutely no guidance on how such 'expansion' should be achieved  - spectacularly unhelpful!

FYI As an aside, I've added a further fix in RC 0.3.1 to use the correct Area Count iteration value. I realised the attribute SF030 Area Count represents (area count - 1), not (area count) as previously handled. This will affect HPAC and GAD payloads but not OCB, and it has no direct bearing on the conversation above. I presume it was done this way so as to accommodate up to 32 iterations in a 5-bit field, but AFAICS it's not explicitly stated in the SPARTN specification.

FYI As an aside, I've added a further fix in RC 0.3.1 to use the correct Area Count iteration value. I realised the attribute SF030 Area Count represents (area count - 1), not (area count) as previously handled.

As part of this change, I've added a protected attribute _padding to all SPARTNMessage objects. This contains the number of redundant bits added to the payload in order to byte-align the payload transport with the exact number of bytes specified in the payload length attribute nData i.e. (actual content length in bits + msg._padding = msg.nData * 8). If the payload has been successfully decrypted and decoded, this value should always be >=0, <=8, so checking the value provides a rough-and-ready (but by no means definitive) indication of successful decryption.

1. What specific criteria are you using to confirm that the HPAC or OCB payloads are in fact being decrypted correctly? Do you have exemplary data to validate the output against?

2. Have you tried using, as a `basedate`, a 32-bit timetag from an OCB-GLO message in the same datastream - i.e. use the 32-bit timetag from an OCB-GLO message with `timeTagtype` = 1 to decrypt one with a 16-bit timetag (`timeTagtype` = 0), without making any further adjustment based on UTC? If so, does it work?

I'm verifying the message is fully parsed (between 0 and 7 bits left and not trying to read above the message limit), as well as that all the Do Not Use (DNU) flags are set to 0, and that the Solution issue of update (SIOU) follow the other messages.
That a really clever idea and would have saved time if I though about it earlier, nice one ! Here are the timestamp in a continuous stream (few seconds of data) :

As you can see, GLO = GPS time + 3600*3 - 18
However, it also seems there is a 14 second difefrence between BeiDou and GPS ... : BeiDou = GPS + 14
I'll edit my message/re-comment when I have more details

Message Name
32 Bit Timestamp
16 Bit Timestamp

SPARTN-1X-GAD

5430

SPARTN-1X-GAD

5430

SPARTN-1X-HPAC-GPS
451488630

SPARTN-1X-HPAC-GPS
451488630

SPARTN-1X-HPAC-GPS
451488630

SPARTN-1X-HPAC-GPS
451488630

SPARTN-1X-HPAC-GPS
451488630

SPARTN-1X-HPAC-GLO
451499412

SPARTN-1X-HPAC-GLO
451499412

SPARTN-1X-HPAC-GLO
451499412

SPARTN-1X-HPAC-GLO
451499412

SPARTN-1X-HPAC-GLO
451499412

SPARTN-1X-HPAC-BEI
451488616

SPARTN-1X-HPAC-BEI
451488616

SPARTN-1X-HPAC-BEI
451488616

SPARTN-1X-HPAC-BEI
451488616

SPARTN-1X-HPAC-BEI
451488616

SPARTN-1X-HPAC-GAL
451488630

SPARTN-1X-HPAC-GAL
451488630

SPARTN-1X-HPAC-GAL
451488630

SPARTN-1X-HPAC-GAL
451488630

SPARTN-1X-HPAC-GAL
451488630

SPARTN-1X-OCB-GPS
451488630

SPARTN-1X-OCB-GLO
451499412

SPARTN-1X-OCB-BEI
451488616

SPARTN-1X-OCB-GAL
451488630

SPARTN-1X-OCB-GPS

5435

SPARTN-1X-OCB-GLO

16217

SPARTN-1X-OCB-BEI

5421

SPARTN-1X-OCB-GAL

5435

SPARTN-1X-OCB-GPS

5440

SPARTN-1X-OCB-GLO

16222

SPARTN-1X-OCB-BEI

5426

SPARTN-1X-OCB-GAL

5440

👍

1. I'm verifying the message is fully parsed (between 0 and 7 bits left and not trying to read above the message limit), as well as that all the Do Not Use (DNU) flags are set to 0, and that the Solution issue of update (SIOU) follow the other messages.

This is essentially what I've been doing as well in debug mode - hopefully the new _padding attribute makes this a bit easier.

As you can see, GLO = GPS time + 3600*3 - 18 However, it also seems there is a 14 second difference between BeiDou and GPS ... : BeiDou = GPS + 14

Yeah different GNSS constellations follow different leap second adjustment rules (I have an old private GitHub branch which was intended to address this for historical logs - I may dust it off sometime). It's not normally a major issue in practice but it's clearly significant in the context of using (reasonably) accurate timestamps to derive cryptographic initialisation vectors (IV). I understand that it's good practice to use 'unpredictable' values in IV derivations, but I really wish u-blox hadn't chosen basedate given all the potential confusion around UTC and leap second adjustments. I suspect their intention was for end users to always use a 32-bit timetag from the same datastream, but this is geared towards 'real time' embedded applications.

FYI see https://github.com/semuconsulting/pyspartn/pull/19 - not sure if this is a complete fix, but it should work OK provided there are sufficient unambiguous 32-bit timetags in the incoming datastream. If you have the time, give this branch a go and let me know how you get on. Feedback and corrections welcome.

I was thinking about doing it simpler (but your PR is obviously a great addition !)
Given a close enough date-time and an ambiguous 16 bits time :

Calculate the unambiguous 32 bits time -> this is T
Add 12 hours to T -> this is T + half a day
Subtract 12h to T -> this is T - half a day
Compare the given date-time to T, T+half, T-half, and look which one is the closest
The closest it the one to be returned

That way, as long as the provided date-time is +/- 6h accurate, the resolution should work, regardless of GNSS time difference (even the +3h of Glonass)
I'll try to open a PR as soon as I can find some time

That would also work.
I think collating 32-bit timetags from the data stream for use as basedates for 16-bit timetags is a solid policy and - I suspect - u-blox's intention for implementation. But the method for providing a 'backup' basedate for when there is no 32-bit timetag available (yet) is up for grabs. Happy to consider alternative approaches.
The basedate provided to SPARTNMessage for an individual message must obviously correspond to that specific message.
I think I'll merge the PR for RC 0.3.2 sooner rather than later as it includes a bunch of other enhancements I've had on the pile for a while now (iincluded automatic conversion of float values and a bunch of enumerations), but we can look to enhance further in RC 0.3.3.

PR has automatically closed this but feel free to re-open, or raise another issue/PR, if you have a better approach.


Comfee MDDF-16DEN7 WF

I updated to the last version of the plug-in and to the homebridge-config-ui-x v4.41.1.
Now I get an error with my dehumidifier.
Before the update it worked nearly perfect.

Unfortunately a reverse of the version did not work.
Can you help get it back to work?

This plugin now support Dehumidifier.
Version 1.1.0

Thanks. Work now with the new version.

But now I get the following warnings every 5 seconds.

Turn on Debug mode on Homebridge settings.
Change positions on your Dehumidifier from your remote or Midea App (Not from homebridge or HomeKit)
and send me log from homebridge.
Please don't send Screenshots.

With the version 1.1.2 I get a different warning and the device is no longer switchable in Homekit.
And there is a themperature sensor present in homebridge, but the device does not have themperature sensors.
Attached logs for 1.1.1 and 1.1.2
homebridge.log_1.1.1.txt
homebridge.log_1.1.2.txt

try version 1.1.3

It gets the same errors. And the Heating Mode ist still present.
The temperature is not supported by the device.
And the device is still not switchable. This works with 1.1.1.

Install version 1.04
Turn on Debug mode on Homebridge settings.
Change positions on your Dehumidifier from your remote or Midea App (Not from homebridge or HomeKit)
and send me this line:
[5/17/2021, 11:41:37 AM] [midea-air] Operational Mode is set to: 0
write the state of the Humidifier. for Example
heat = Operational Mode [the number you get from homebridge log]
I need all the positions.

On No Modus - High Vent
[5/18/2021, 9:48:45 AM] [midea-air] [updateValues] Command + Header: 90,90,1,0,89,0,32,0,1,0,0,0,39,36,17,9,13,10,18,20,218,73,0,0,0,16,0,0,0,0,0,0,0,0,0,0,0,0,0,0,170,32,161,0,0,0,0,0,3,3,65,33,0,255,3,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,11,36,164,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[5/18/2021, 9:48:46 AM] [midea-air] [MideaPlatform.ts] sendCommand (Intent: [updateValues] (fetch params?) attempt 1/2) success!
[5/18/2021, 9:48:46 AM] [midea-air] [Dehumidifier] Current Humidity is 63
[5/18/2021, 9:48:46 AM] [midea-air] [Dehumidifier] Target humidity is set to 40
[5/18/2021, 9:48:46 AM] [midea-air] [Dehumidifier] Water level is at 0
[5/18/2021, 9:48:46 AM] [midea-air] fanSpeed is set to 80
[5/18/2021, 9:48:46 AM] [midea-air] swingMode is set to 8
[5/18/2021, 9:48:46 AM] [midea-air] powerState is set to true
[5/18/2021, 9:48:46 AM] [midea-air] operational mode is set to 0
[5/18/2021, 9:48:46 AM] [midea-air] Full data is [
'11001000', '1',       '1',    '1010000',
'1111111',  '1111111', '0',    '101000',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'111111',   '1011100', '0',    '0',
'0',        '0',       '1011', '11110011',
'1011110',  '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0'
]
[5/18/2021, 9:48:46 AM] [midea-air] [updateValues] Sent update command to 161
Dry - fixed Vent
[5/18/2021, 9:53:45 AM] [midea-air] [updateValues] Command + Header: 90,90,1,0,89,0,32,0,1,0,0,0,39,36,17,9,13,10,18,20,218,73,0,0,0,16,0,0,0,0,0,0,0,0,0,0,0,0,0,0,170,32,161,0,0,0,0,0,3,3,65,33,0,255,3,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,11,36,164,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[5/18/2021, 9:53:45 AM] [Hue] Philips hue: request 87: GET /lights
[5/18/2021, 9:53:45 AM] [Hue] Philips hue: request 87: 200 OK
[5/18/2021, 9:53:45 AM] [midea-air] [MideaPlatform.ts] sendCommand (Intent: [updateValues] (fetch params?) attempt 1/2) success!
[5/18/2021, 9:53:45 AM] [midea-air] [Dehumidifier] Current Humidity is 51
[5/18/2021, 9:53:45 AM] [midea-air] [Dehumidifier] Target humidity is set to 40
[5/18/2021, 9:53:45 AM] [midea-air] [Dehumidifier] Water level is at 0
[5/18/2021, 9:53:45 AM] [midea-air] fanSpeed is set to 80
[5/18/2021, 9:53:45 AM] [midea-air] swingMode is set to 8
[5/18/2021, 9:53:45 AM] [midea-air] powerState is set to true
[5/18/2021, 9:53:45 AM] [midea-air] operational mode is set to 0
[5/18/2021, 9:53:45 AM] [midea-air] Full data is [
'11001000', '1',       '100',  '1010000',
'1111111',  '1111111', '0',    '101000',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'110011',   '1011010', '0',    '0',
'0',        '0',       '1011', '101101',
'101111',   '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0'
]
[5/18/2021, 9:53:45 AM] [midea-air] [updateValues] Sent update command to 161
Continuous - high Vent
[5/18/2021, 9:55:45 AM] [midea-air] [updateValues] Command + Header: 90,90,1,0,89,0,32,0,1,0,0,0,39,36,17,9,13,10,18,20,218,73,0,0,0,16,0,0,0,0,0,0,0,0,0,0,0,0,0,0,170,32,161,0,0,0,0,0,3,3,65,33,0,255,3,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,11,36,164,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[5/18/2021, 9:55:45 AM] [Hue] Philips hue: request 111: GET /lights
[5/18/2021, 9:55:45 AM] [Hue] Philips hue: request 111: 200 OK
[5/18/2021, 9:55:45 AM] [midea-air] [MideaPlatform.ts] sendCommand (Intent: [updateValues] (fetch params?) attempt 1/2) success!
[5/18/2021, 9:55:45 AM] [midea-air] [Dehumidifier] Current Humidity is 51
[5/18/2021, 9:55:45 AM] [midea-air] [Dehumidifier] Target humidity is set to 40
[5/18/2021, 9:55:45 AM] [midea-air] [Dehumidifier] Water level is at 0
[5/18/2021, 9:55:45 AM] [midea-air] fanSpeed is set to 80
[5/18/2021, 9:55:45 AM] [midea-air] swingMode is set to 8
[5/18/2021, 9:55:45 AM] [midea-air] powerState is set to true
[5/18/2021, 9:55:45 AM] [midea-air] operational mode is set to 0
[5/18/2021, 9:55:45 AM] [midea-air] Full data is [
'11001000', '1',       '10',   '1010000',
'1111111',  '1111111', '0',    '101000',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'110011',   '1011010', '0',    '0',
'0',        '0',       '1011', '1100011',
'11111011', '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0'
]
[5/18/2021, 9:55:45 AM] [midea-air] [updateValues] Sent update command to 161
Continuous - low Vent
[5/18/2021, 9:56:45 AM] [midea-air] [updateValues] Command + Header: 90,90,1,0,89,0,32,0,1,0,0,0,39,36,17,9,13,10,18,20,218,73,0,0,0,16,0,0,0,0,0,0,0,0,0,0,0,0,0,0,170,32,161,0,0,0,0,0,3,3,65,33,0,255,3,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,11,36,164,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[5/18/2021, 9:56:45 AM] [Hue] Philips hue: request 123: GET /lights
[5/18/2021, 9:56:45 AM] [Hue] Philips hue: request 123: 200 OK
[5/18/2021, 9:56:45 AM] [midea-air] [MideaPlatform.ts] sendCommand (Intent: [updateValues] (fetch params?) attempt 1/2) success!
[5/18/2021, 9:56:45 AM] [midea-air] [Dehumidifier] Current Humidity is 50
[5/18/2021, 9:56:45 AM] [midea-air] [Dehumidifier] Target humidity is set to 40
[5/18/2021, 9:56:45 AM] [midea-air] [Dehumidifier] Water level is at 0
[5/18/2021, 9:56:45 AM] [midea-air] fanSpeed is set to 40
[5/18/2021, 9:56:45 AM] [midea-air] swingMode is set to 8
[5/18/2021, 9:56:45 AM] [midea-air] powerState is set to true
[5/18/2021, 9:56:45 AM] [midea-air] operational mode is set to 0
[5/18/2021, 9:56:45 AM] [midea-air] Full data is [
'11001000', '1',       '10',   '101000',
'1111111',  '1111111', '0',    '101000',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'110010',   '1011010', '0',    '0',
'0',        '0',       '1011', '100',
'10000011', '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0'
]
[5/18/2021, 9:56:45 AM] [midea-air] [updateValues] Sent update command to 161
Continuous - mid Vent
[5/18/2021, 9:58:45 AM] [midea-air] [updateValues] Command + Header: 90,90,1,0,89,0,32,0,1,0,0,0,39,36,17,9,13,10,18,20,218,73,0,0,0,16,0,0,0,0,0,0,0,0,0,0,0,0,0,0,170,32,161,0,0,0,0,0,3,3,65,33,0,255,3,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,11,36,164,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[5/18/2021, 9:58:45 AM] [Hue] Philips hue: request 147: GET /lights
[5/18/2021, 9:58:45 AM] [Hue] Philips hue: request 147: 200 OK
[5/18/2021, 9:58:45 AM] [midea-air] [MideaPlatform.ts] sendCommand (Intent: [updateValues] (fetch params?) attempt 1/2) success!
[5/18/2021, 9:58:45 AM] [midea-air] [Dehumidifier] Current Humidity is 50
[5/18/2021, 9:58:45 AM] [midea-air] [Dehumidifier] Target humidity is set to 40
[5/18/2021, 9:58:45 AM] [midea-air] [Dehumidifier] Water level is at 0
[5/18/2021, 9:58:45 AM] [midea-air] fanSpeed is set to 60
[5/18/2021, 9:58:45 AM] [midea-air] swingMode is set to 8
[5/18/2021, 9:58:45 AM] [midea-air] powerState is set to true
[5/18/2021, 9:58:45 AM] [midea-air] operational mode is set to 0
[5/18/2021, 9:58:45 AM] [midea-air] Full data is [
'11001000', '1',       '10',   '111100',
'1111111',  '1111111', '0',    '101000',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'110010',   '1011010', '0',    '0',
'0',        '0',       '1011', '11111',
'1010100',  '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0'
]
[5/18/2021, 9:58:45 AM] [midea-air] [updateValues] Sent update command to 161
Smart - high Vent
[5/18/2021, 10:00:45 AM] [midea-air] [updateValues] Command + Header: 90,90,1,0,89,0,32,0,1,0,0,0,39,36,17,9,13,10,18,20,218,73,0,0,0,16,0,0,0,0,0,0,0,0,0,0,0,0,0,0,170,32,161,0,0,0,0,0,3,3,65,33,0,255,3,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,11,36,164,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[5/18/2021, 10:00:45 AM] [Hue] Philips hue: request 171: GET /lights
[5/18/2021, 10:00:45 AM] [Hue] Philips hue: request 171: 200 OK
[5/18/2021, 10:00:45 AM] [midea-air] [MideaPlatform.ts] sendCommand (Intent: [updateValues] (fetch params?) attempt 1/2) success!
[5/18/2021, 10:00:45 AM] [midea-air] [Dehumidifier] Current Humidity is 50
[5/18/2021, 10:00:45 AM] [midea-air] [Dehumidifier] Target humidity is set to 40
[5/18/2021, 10:00:45 AM] [midea-air] [Dehumidifier] Water level is at 0
[5/18/2021, 10:00:45 AM] [midea-air] fanSpeed is set to 80
[5/18/2021, 10:00:45 AM] [midea-air] swingMode is set to 8
[5/18/2021, 10:00:45 AM] [midea-air] powerState is set to true
[5/18/2021, 10:00:45 AM] [midea-air] operational mode is set to 0
[5/18/2021, 10:00:45 AM] [midea-air] Full data is [
'11001000', '1',       '11',   '1010000',
'1111111',  '1111111', '0',    '101000',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'110010',   '1011010', '0',    '0',
'0',        '0',       '1011', '10110100',
'10101010', '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0'
]
[5/18/2021, 10:00:45 AM] [midea-air] [updateValues] Sent update command to 161
Off
[5/18/2021, 10:24:45 AM] [midea-air] [updateValues] Command + Header: 90,90,1,0,89,0,32,0,1,0,0,0,39,36,17,9,13,10,18,20,218,73,0,0,0,16,0,0,0,0,0,0,0,0,0,0,0,0,0,0,170,32,161,0,0,0,0,0,3,3,65,33,0,255,3,0,0,2,0,0,0,0,0,0,0,0,0,0,0,0,11,36,164,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
[5/18/2021, 10:24:45 AM] [Hue] Philips hue: request 459: GET /lights
[5/18/2021, 10:24:45 AM] [Hue] Philips hue: request 459: 200 OK
[5/18/2021, 10:24:45 AM] [midea-air] [MideaPlatform.ts] sendCommand (Intent: [updateValues] (fetch params?) attempt 1/2) success!
[5/18/2021, 10:24:45 AM] [midea-air] [Dehumidifier] Current Humidity is 57
[5/18/2021, 10:24:45 AM] [midea-air] [Dehumidifier] Target humidity is set to 75
[5/18/2021, 10:24:45 AM] [midea-air] [Dehumidifier] Water level is at 0
[5/18/2021, 10:24:45 AM] [midea-air] fanSpeed is set to 80
[5/18/2021, 10:24:45 AM] [midea-air] swingMode is set to 11
[5/18/2021, 10:24:45 AM] [midea-air] powerState is set to false
[5/18/2021, 10:24:45 AM] [midea-air] operational mode is set to 0
[5/18/2021, 10:24:45 AM] [midea-air] Full data is [
'11001000', '0',       '1',    '1010000',
'1111111',  '1111111', '0',    '1001011',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'111001',   '1011010', '0',    '0',
'0',        '0',       '1011', '11100101',
'1010010',  '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0',
'0',        '0',       '0',    '0'
]
[5/18/2021, 10:24:45 AM] [midea-air] [updateValues] Sent update command to 161
The operational mode does not change.
It looks like the mode is in the Full data part.
first row, second column = On/off
first row, third column = Mode
But, for me only the on/off function and the humidity is nescessary. Everthin else is a benefit.

try version 1.1.4-beta.1

it's lock like the swing mode is deferent from AC.
Can you send me swingMode numbers and write my witch position is it?
it's on this line: [5/18/2021, 10:24:45 AM] [midea-air] swingMode is set to 11
I think it's like this correct me if I'm wrong
swingMode 0 = None
swingMode 8 = Horizontal
swingMode 11 = Vertical
swingMode XX = Both

I am building a plugin that will fit as many devices as possible.
So for you on/off and humidity is enough but not for me!
I don't have Dehumidifier so it's a little bit hard to build.
I fix the fanSpeed (release on next beta) and I want to fix swingMode.
Can you send me the positions of swing mode.
0 = None
8 = XXXX
11 = XXXX
when you change the positions you'll get it on homebridge log
if you can write for me the position you press and the number you get from the log

I changed all settings directly on the device and it stayed on swing mode 13.
I don't think it supports this. What is the purpose of the swing mode?
As far as I can see is:
Current Humidity is 57 = Humidity sensor
Target humidity is set to 75 = Setting of the target humidity (like temperature setting on an AC)
Water level is at 0 = Sensor of the water tank (0=empty, 100=full)
fanSpeed is set to 80 = Power of the fan
swingMode is set to 13 = I can't reproduce a change of this
powerState is set to false = Power On/Off
Beside of the different modes like Dryer, Smart, Continuous and No Mode, the above settings are all the device is capable of.

This are settings in the App.

Version 1.1.4-beta.2 works for you?

No, it is not working. I get again these errors:
This plugin generated a warning from the characteristic 'Target Heater-Cooler State': characteristic value expected valid finite number and received "undefined" (undefined). See https://git.io/JtMGR for more info.
This plugin generated a warning from the characteristic 'Cooling Threshold Temperature': characteristic was supplied illegal value: number 0 exceeded minimum of 17. See https://git.io/JtMGR for more info.
This plugin generated a warning from the characteristic 'Heating Threshold Temperature': characteristic was supplied illegal value: number 0 exceeded minimum of 17. See https://git.io/JtMGR for more info.
Somehow the temperature values have to be removed for the dehumidifier. It has no temperature values.

I hope that now it will work
version 1.1.4-beta.3

i deinstalled to plugin and then reinstalled it.
Now I do not get the dehumidifier option anymore. I only have the heating device.
Attached the log. I deleted all unnecessary stuff.
homebridge.log.txt

Do you have Discord?

Yes

Yossi#1563

Problem fix on version 1.1.4


Add detail about colorbox third text parameter

As stated in issue #1766

[clabot:check]

Wording is perfect now! No further changes seem necessary.
I see what you mean with remarkable-katex and it's braceLevel issue. Hope it gets fixed soon by the maintainer.
If that doesn't happen:

you may change the configuration of it {delimiter: '$'} for other one in the Katex documentation and avoid the problem alltoguether.
maybe you or me or someone can send the PR to remarkable-katex. We'll see :)

Hi everyone. Developer for the remarkable-katex plugin. Thanks for raising the issue. I've implemented a fix and my test case  mdWithDollar.render('Equation $\\colorbox{aqua}{$F=ma$}$.') passes. I've pushed a new version 1.1.5. Please let me know if there are still issues.

Codecov Report

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

@@           Coverage Diff           @@
##           master    #2280   +/-   ##
=======================================
  Coverage   88.54%   88.54%
=======================================
  Files          84       84
  Lines        5370     5370
  Branches      942      942
=======================================
  Hits         4755     4755
  Misses        542      542
  Partials       73       73

Flag
Coverage Δ

#test
88.54% <ø> (ø)

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 7523e97...d689d4a. Read the comment docs.

@bradhowes Wow, that was fast! Thanks for taking that on and fixing!
I just pushed a new version and https://deploy-preview-2280--katex.netlify.app/docs/next/supported.html#style-color-size-and-font now looks good to me. If someone (@ronkok?) could spot check the rest to make sure there aren't any new issues, that would be appreciated.
@ylemkimon I changed the way that remarkable-katex is embedded, ignoring it in .eslintignore instead of changing its style to conform to ours, so it's easier to upgrade in the future. (I tried to use it as an NPM package, but I see the issue is that we need to require("../..") instead of require("katex").) Let me know if you disagree with that approach / have a better idea!


Test face verification

[ ] check normal flow is working (when user claims)

user shouldnt be able to claim if not whitelisted

[ ] delete account flow
[ ] try to spoof, make faces, glasses etc...

@AnastasiiaOdnoshevna this issue is for you

Checked on the DEV env. V0.22.1-0

normal flow is working. The user tries to claim and then the face verification screen is displayed and then this verification is passed successfully if the real face is used
deleting the account is performed successfully
the user can't pass the verification when the user tries to scan face from printed photo /portrait/PC screen/ or using glasses

@AnastasiiaOdnoshevna

verify user open account and complete face verification after deleting
verify user cant open another account and pass face verification (ie
should get duplicate error)
test error screens

User can complete the verification and can't create a new account if his face is present in the database
The user gets some screen matched to the error message
Checked on DEV/QA V0.22.1-2
LG V30+ // Android 8.0 // Google Chrome 81.0.4044.138
Desktop: Windows 10 // Google Chrome 83.0.4103.61


Return error to the client when calling walletrpc SignPsbt when signing fails

Background
In the new walletrpc method SignPsbt it allows you to sign a PSBT, but if you pass a PSBT that has nothing for the node to sign it will fail to add signatures since it has nothing to sign, but this failure will be silent. If you are using this API and you think you have passed something to sign, the successful response could make you think that signing completed successfully when in fact nothing was signed.
Your environment

lnd 0dae2d47f20b924c72a798d551537c5d9de8f86a

Steps to reproduce

Pass a PSBT to the SignPsbt method that has no inputs that the node can sign and get a resulting signed_psbt

Expected behavior
The API should complain that it didn't receive anything to sign
Actual behavior
It returns a signed_psbt result that may in fact not actually be signed
Workaround
If you compare the resulting PSBT with the original PSBT and they are byte for byte equal, this indicates nothing was signed

@alexbosworth your issue was addressed in #6771.
Release notes info:
https://github.com/lightningnetwork/lnd/blob/master/docs/release-notes/release-notes-0.16.0.md#rpc
Please close this issue if it has been resolved.

Fixed by #6771. Not returning an error was always on purpose as that can be useful for some flows.
With #6771 the caller now has a better option to find out if anything was signed at all.


Optionally handle onDragStart event

I had a case where I needed to override the event.dataTransfer.effectAllowed on dragStart, so this PR allows us to optionally pass in a function to handle such a thing.
onDragStart (e) {
  e.dataTransfer.effectAllowed = "move";
},

render () {
  return <Dropzone onDragStart={this.onDragStart}></Dropzone>
}

Do you mind adding tests for it please? I'm ready to merge it as soon as we get it covered with tests. Thanks!

My apologies @okonet. Added!

Nothing to apologise! Awesome work and thanks for contribution!


tool traceconv and trace_processor can not find GLIBC_2.33 and GLIBC_2.34

I want use  traceconv and trace_processor  tool these days, But get errors,  please help me fix this:
/home/xxx/.local/share/perfetto/prebuilts/trace_processor_shell: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /home/xxx/.local/share/perfetto/prebuilts/trace_processor_shell)
/home/xxx/.local/share/perfetto/prebuilts/trace_processor_shell: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/xxx/.local/share/perfetto/prebuilts/trace_processor_shell)

my pc:
uname -a
Linux xxxpc 5.15.0-124-generic #134~20.04.1-Ubuntu SMP Tue Oct 1 15:27:33 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

and libc versions:
strings /lib/x86_64-linux-gnu/libc.so.6 | grep GLIBC_2
GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
GLIBC_2.18
GLIBC_2.22
GLIBC_2.23
GLIBC_2.24
GLIBC_2.25
GLIBC_2.26
GLIBC_2.27
GLIBC_2.28
GLIBC_2.29
GLIBC_2.30

Unfortunately lyour version of Linux is too old to run the prebuilts we provide. glibc 2.33 was released in 2021 (https://sourceware.org/pipermail/libc-alpha/2021-February/122207.html) so your Linux version has some version before this.
We don't really have the resources to release prebuilts to support older versions of Linux due to the centralised way releases are generated.
To fix this issue in your side, you would need to compile trace processor from sources. Please see https://perfetto.dev/docs/contributing/getting-started#quickstart for how to do this.


First take on flutter start for iOS devices

lgtm.
I think we should refactor the code so that we don't need any of these switches based on platform, though. All the platform-specific code should be in platform-specific classes, and the main code should just drive it without knowledge of the differences.

@Hixie: I am landing this now. @devoncarew is also planning to refactor device.dart. Will pick this up again after.

Oh yeah, totally. I didn't mean for that comment to prevent check-in. Just "directions for future research".


Adding Campaign's extension of Experience Events.

Fix Issue #206
This extension is needed for campaign's experienceEvents to be represented in XDM.
Please review: @trieloff @kstreeter @cmathis @cdegroot-adobe

Gentle nudge to @lrosenthol @trieloff to please re-review with the latest changes.

From my point of view:

[ ] fix https://github.com/adobe/xdm/pull/209#discussion_r180053125
[ ] decide what to do with businessContext: either you take it out or you document what the allowed value and semantics of the field are.

As a representative of the offer management core service I strongly urge that campaign does not introduce an offer XDM under https://ns.adobe.com/xdm-extensions/adobe/experience/campaign/offer
@dmitry-shkolnik is going to introduce a comprehensive set of models for Offer Management in general

Our initial set of XDMs for Offer Management is now available for the review at https://github.com/adobe/xdm/pull/245

@trieloff Can this be merged now please?

thanks for noticing this. fixed.


gammainc should return 1.0 instead of NaN for infinite x

See http://en.wikipedia.org/wiki/Incomplete_gamma_function#Asymptotic_behavior.  Note that scipy.special.gammainc is documented as Incomplete gamma function but is more specifically the 'regularized lower incomplete gamma function'.

gdtr appears to have the same problem.

Here's a PR related to incomplete gamma edge cases https://github.com/scipy/scipy/pull/27.

Has been fixed in gh-5395, closing.


crd-docs-generator CI changes fail because go fmt modifies testdata

PR: https://github.com/giantswarm/crd-docs-generator/pull/123

I created a more detailed issue in the crd-docs-generator repo, as that project is used by people outside Giant Swarm, too.
https://github.com/giantswarm/crd-docs-generator/issues/124
Closing this one.


Update code to resolve Fidelity check errors

This PR makes two updates to resolve the Fidelity check errors mentioned in https://github.com/chorus-ai/chorus_waveform/issues/62:

It changes the tolerance used during the fidelity check to be based on the bit resolution of the signal
It uses the max gain across segments for CCDEF

This update does not appear to be related to the Fidelity check error for CCDEF in https://github.com/chorus-ai/chorus_waveform/issues/64

@briangow rebasing on main should fix your error on the benchmark workflow.

@briangow something odd about the commits here. It looks like the same two commits are repeated?

"update fidelity check tolerance - bit resolution" * 2
"ccdef benchmarking - use max gain" * 2

Might be easiest to rebase on main, reset to the top of main, then add the commits again?

@tompollard , I did the rebase and force pushed so it should only have one of each of my commits now. Looks like the Github action is passing now - thanks for the update.
Might be good to give @wa6gz a chance to review this before merging since it makes changes to his code.

Thanks @briangow for pointing this out - the max gain fix looks good. I built on this branch to fix #64. I used the baseline calculation in @bemoody's WFDB code, added an attribute to the HDF5 file, and changed the reader accordingly. The record from #64 (charis1) now runs without error.

Thanks @wa6gz !


Turn resume collection script into background job

This task from BrickHack is used to generate a .zip of resumes to provide sponsors: https://github.com/codeRIT/brickhack.io/blob/develop/lib/tasks/tools.rake#L31-L85
This should be turned into:

A background job instead of a Rails task
Can start the job from the management UI
Sends an email to the admin that initiated it once it is complete (or failed)

Fixed link: https://github.com/codeRIT/brickhack.io/blob/b9dbb6a07930696ce7b706b4ee7d73bc264d0119/lib/tasks/tools.rake#L32
We’ve also switched off the paper-clip gem and now handle resume files natively using ActiveStorage, so the code we’ll be running will be slightly different
Maybe want to add a new table to the database that logs these as “admin downloads” or something. Could be re-used to generate a full DB dump at the end of the year


QR code identification

The code as it is doesn't have any structure in place for reading QR codes.
see here for a stand-alone implementation of the ZBar library for reading QR codes that we used at the last competition.
I recommend using ZBar for now, though feel free to look into other libraries later and compare them to ZBar.
How to implement:
A QR code handling class should be added to the targetid module.
Fields to store QR code data should be added to the PixelTarget class (in the core module)
A cropped image of the target should also be added to PixelTarget (for now assume that it will be created by some other part of the library, we'll get someone else to implement the cropping of the image)
Appropriate libraries (ZBar) need to be added to modules/targetid/CMakeLists.txt
A suite of tests should be written testing QR codes of different sizes and qualities (include tests with blurry images, small bar code images)
This should be a good general introduction to the codebase since it touches most aspects of the project.

@SarahMadigan
I believe you expressed an interest in QR code identification at Tuesday's meeting, you might want to look at this.


[CARBONDATA-1110] put if clause out of the for clause

it should be better to put if clause out of the for clause

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/2144/

retest this please

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/2148/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/carbondata-pr-spark-2.1/42/Failed Tests: 1carbondata-pr-spark-2.1/org.apache.carbondata:carbondata-spark-common-test: 1org.apache.carbondata.spark.testsuite.allqueries.InsertIntoCarbonTableTestCase.insert into carbon table from carbon table union query

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/carbondata-pr-spark-1.6/13/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/2161/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/carbondata-pr-spark-2.1/55/Failed Tests: 9carbondata-pr-spark-2.1/org.apache.carbondata:carbondata-spark-common-test: 9org.apache.carbondata.integration.spark.testsuite.dataload.TestLoadDataWithAutoLoadMerge.test data loading with auto load mergeorg.apache.carbondata.spark.testsuite.partition.TestDataLoadingForPartitionTable.data loading for partition table: range partitionorg.apache.carbondata.spark.testsuite.partition.TestDataLoadingForPartitionTable.data loading for partition table: list partitionorg.apache.carbondata.spark.testsuite.partition.TestDataLoadingForPartitionTable.Insert into for partition table: hash partitionorg.apache.carbondata.spark.testsuite.partition.TestDataLoadingForPartitionTable.Insert into for partition table: range partitionorg.apache.carbondata.spark.testsuite.partition.TestDataLoadingForPartitionTable.Insert into partition table: list partitionorg.apache.carbondata.spark.testsuite.partition.TestDataLoadingForPartitionTable.multiple data loading for partition tableorg.apache.carbondata.spark.testsuite.partition.TestDataLoadingForPartitionTable.multiple insertInto for partition tableorg.apache.carbondata.spark.testsuite.partition.TestDataLoadingForPartitionTable.multiple data loading and insertInto for partition table

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/carbondata-pr-spark-1.6/26/Failed Tests: 4carbondata-pr-spark-1.6/org.apache.carbondata:carbondata-spark-common-test: 4org.apache.carbondata.spark.testsuite.dataload.MultiFilesDataLoagdingTestCase.test data loading for multi files and nested folderorg.apache.carbondata.spark.testsuite.iud.HorizontalCompactionTestCase.test IUD Horizontal Compaction Check Column Cardinalityorg.apache.carbondata.spark.testsuite.iud.HorizontalCompactionTestCase.test IUD Horizontal Compaction Segment Delete Test Caseorg.apache.carbondata.spark.testsuite.iud.HorizontalCompactionTestCase.test case full table delete

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/2198/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/carbondata-pr-spark-1.6/65/Failed Tests: 1carbondata-pr-spark-1.6/org.apache.carbondata:carbondata-spark-common-test: 1org.apache.carbondata.spark.testsuite.allqueries.InsertIntoCarbonTableTestCase.insert into carbon table from carbon table union query

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/2286/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/carbondata-pr-spark-1.6/159/

Can one of the admins verify this patch?

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/2350/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/carbondata-pr-spark-1.6/229/

Thanks for working on this. This looks like duplicate of #990 which is already merged. So please close the same.
Rebased changes or new changes can always be pushed to same PR branch from any local branch using force push option. Not required to raise new PRs.
git push -uf  :


UI and UX Changes

UI and UX Changes
I just check out your website and I found that your website needs a little spice up of UI and UX .
so, please assigned me for it I hope I will not disappoint you.

@Morbius00 Can you discuss the changes with us in our discord forum and elaborate what changes you will do then we'll create an issue for you.


Add a go mod tidy git hook

What does this PR do?

Add a go mod tidy git hook which checks that all go.mod and go.sum files are clean.
Motivation

This is a common error which is often caught in CI.
Having a hook to catch it before pushing is way better, gain a lot of time.
Additional Notes

Due to the replace directives in this repo, a change in any go file can cause a change in any go.mod file.

It's possible to do something smarter, but this is better than nothing.
The hook is a pre-push hook, because it takes several seconds to run (4s when clean, 10s if there was a go file changed), and I don't want to delay every commit.
If you already installed pre-commit, you need to install it again so that pre-push hooks run too (not just pre-commit hooks).
The hook could call inv tidy-all and commit in case of changes but it's much safer to let the user fix any issue.
For this reason I set GOPROXY=off so that any modules needing to be downloaded makes the hook fail.
Example failure (when importing a new dependency in pkg/gohai without tidy):
❯ git push
go-mod-tidy..............................................................Failed
- hook id: go-mod-tidy
- exit code: 1

go: finding module for package k8s.io/client-go/tools/clientcmd
go: github.com/DataDog/datadog-agent/pkg/gohai imports
	k8s.io/client-go/tools/clientcmd: cannot find module providing package k8s.io/client-go/tools/clientcmd: module lookup disabled by GOPROXY=off

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided. Except if the qa/skip-qa label, with required either qa/done or qa/no-code-change labels, are applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

/merge


Move config.py to client dir

Having the library create a default empty Config() object doesn't actually do anything - it will always be empty, so we'll always need to pass in username / password via function parameters. And since the application always needs to pass data in via parameters, even if it wasn't empty (eg if the user manually created config.json by hand), the library config would still be overridden by the client config.
Since the library config does nothing except add confusion, and the client config reads and writes and does all the work, I think it makes more sense for it to be part of the client - which also means that the library itself can be kept as a simpler pure network wrapper :)

But it enables users to set credentials using the CLI and then use the library without specifying the credentials every time.

I am confused - are users typically using the library directly, without an app in front of it?
I'd think whatever app is being written based on top of the library, that app would want to be in charge of asking the user for their login details - Like if somebody was building MyGuiSubtitleDownloader, I expect that that app would pop up a GUI message box prompting for username and password - it'd be weird to say "use the ost CLI to set username and password so that MyGuiSubtitleDownloader can then read it"
Alternatively if the goal is that every subtitle-downloader app that a user installs should share a single configuration, and when you log into one app it logs into all of them, then having the Config object in the library does make sense. Having one config file shared by many apps feels weird to me though ^^; If we do want to go in that direction then ok, but in that case I'd suggest merging things in the other direction (with the app modifying the library's Config object, instead of both the app and the library creating their own Configs)

I'm thinking of something similar to the AWS CLI and SDK (boto3). You'd configure a file with credentials, and it could be optionally used by both the command line and Python library. Developers often switch between the CLI and library for different tasks, so a unified config file would simplify things.


Dependency order example

Hi DMLCers:
I'm reading https://github.com/dmlc/mxnet/blob/master/doc/developer-guide/note_engine.md.
In this figure
https://github.com/dmlc/dmlc.github.io/blob/master/img/mxnet/engine/dep_simple.png,
do you actually mean D = B * C because it seems that D = A * C doesn't depend on B?

Sorry for the delayed reply. Yes you are right. Thanks for the catch!

The figure has been updated. Thanks!
I have added you to the  https://github.com/dmlc/mxnet/blob/master/CONTRIBUTORS.md .
Hope we can get more of your contribution to mxnet

If you like, I can help update the documentation, as well as fix some typos and wording issues. So you can focus on development.

That will be really awesome. We think the notes and ideas are as(more) important as the code itself, and it is really nice if you like to share your piece of wisdom with the community

Please feel free to send the pull request.

Solved by https://github.com/bryandeng/mxnet/commit/a3542fd48a66e8f9a78bd4e1c643c65159e5ba46 and #280.


Added beans.xml to support brave-jaxrs2 in CDI environments

This commit adds META-INF/beans.xml to brave-core, brave-http and brave-jaxrs2. This allows it to be used in CDI based environments, which otherwise wouldn't be able to scan the resources.
With regard to the existing implementation, I think this doesn't have any impact.

Looks like brave-grpc failed:
[INFO] brave-grpc ......................................... FAILURE [  7.032 s]

I'll have a look.

I am not able to reproduce this error. Maybe an intermittent failure? Would it be possible that someone kicks off another test run?

@heiko-braun sorry about the build flake. ps is there a way to test this change works? ex bring in a test dep that would load this file in a unit test?

wait this is adding beans files to even non java ee modules. I'm not sure if this is something we want to guarantee. What's the impact of not doing this?

Thanks for the feedback @adriancole .
With regard to testing:
Do you think about just loading the file to verify it's packaged correctly, or something more elaborate the verifies the libraries in a CDI environment? I think the later would at quiet some considerable bloat to the test and the project a as a whole.
With regard to your second question:
both brave-http and brave-core are transitive deps of brave-jaxrs2. Discovery in a CDI env requires either a META-INF/beans.xml or bean defining annotations on relevant classes. I think the later is what's causing the problem. If you look at BraveContainerResponseFilter for instance it uses @Inject on the ctor, but the injected param ServerResponseInterceptor, which comes from brave-core doesn't use any defining annotations.
To overcome this problem, I thought it would be the most simple to just add META-INF/beans.xml to all relevant libraries.

This seems more to me that the historically added Inject annotation is the
real problem. There are few things in brave that make sense to wire based
solely on types and wildcarding every jar seems questionable.
Ex Brave is an object graph in itself, so we typically pass that around
after it has been constructed. What if you were to make a configuration
class for Brave in CDI similar to how folks are using spring?

That would work too, but it implies we remove the remaining @Inject annotations, if I understand you correctly.

yeah. a better punch to take imho. I'd rather mention this in the release
notes (the removal of the inject annotations).

I agree. Let close this PR and I'll prepare another one with changes you suggested.

ps @heiko-braun I noticed your work on swarm.. cool stuff! If you get to a point where you want to have it listed on zipkin.io, raise a PR here https://github.com/openzipkin/openzipkin.github.io/blob/master/_data/community_instrumentations.yml

@adriancole thanks, I'll do that once our implementation is in a reasonable shape and properly documented.

:thumbsup:


Response status is missing in OnHold State list

Describe the bug in current situation
If the request has gone through response and then on hold. There should be an option to IAO to change the state back to response. Currently only CFR and Closed is listed when you are on OnHold state.
Link bug to the User Story
Impact of this bug
Describe the impact, i.e. what the impact is, and number of users impacted.
Chance of Occurring (high/medium/low/very low)
Pre Conditions: which Env, any pre-requesites or assumptions to execute steps?
Steps to Reproduce
Steps to reproduce the behavior:

Go to foi-flow request
Traverse through Response and then OnHold state
Check the status dropdown
See error

Actual/ observed behaviour/ results
The dropdown shows CFR and Closed
Expected behaviour
The dropdown should show Response and Closed
Screenshots/ Visual Reference/ Source
If applicable, add screenshots to help explain your problem. You an use screengrab.

Don't forget to add an estimate to this when you push the fix to test @divyav-aot

working as expected, so closing it


X-Camera patch

Amy,
Thanks for Creating the headtrack plugin for  X-plane.  Freetrack don't seem to work for me anymore on Linux with OpenTrack.  Headtrack over UDP has been a great replacement.  Only issue is it doesn't work with X-Camera.
Mark Ellis, creator of X-Camera, put up a patch for it here (https://github.com/amyinorbit/headtrack/pull/5/files).
I understand you have a lot going on.  I applied Mark's patch and compiled it for Linux.  I am by no means a programmer.  Took me a couple of evenings to get it to compile.  Eventually I create a virtual machine with Kubuntu LTS and only the required dependencies installed to get it to compile.  The compile plugin can be found here (https://github.com/CannonFodderSE/Headtrac-X-camera) until you release an official package.
Thanks for your great work!
Randy Bancroft
P.S Edinburgh is a beautiful place.  My wife and I were there two years ago.  Loved it.

Thanks you, it works like a charm!

mathieureygaerts,
Glad it worked  for you.
Are you running OpenTrack with neuralnet tracker on Linux?  If so, how did you get it to work?  I can't get neuralnet to compile.
Randy


Failed to make a client connection to queue manager  with ACE12 V9 and V10.

Hi!,
I'm building an environment with ACE12 and IBM MQ images on Docker, that allow me to a deploy some solutions, and do unit test.
For this purpose I wrote the following docker compose file:
version: '3.9'
services:
  aceserver:
    image: arnold9810/ace12v9r1:V0
    container_name: serverace
    ports:
      - 7600:7600
      - 7800:7800
      - 7843:7843
    depends_on:
      - mqdev
    networks:
      - ace-mq-net
    environment:
      LICENSE: accept
      ACE_SERVER_NAME: ACESERVER
    restart: always
  mqdev:
    image: icr.io/ibm-messaging/mq:latest
    container_name: MQDEV
    environment:
      LICENSE: accept
      MQ_QMGR_NAME: MQDEV
      MQ_APP_PASSWORD: passw0rd
      MQ_ADMIN_PASSWORD: passw0rd
      MQSNOAUT: 'Yes'
    ports:
      - 1414:1414
      - 9157:9157
      - 9443:9443
    volumes:
      - mqvolume:/mnt/mqm
    networks:
      - ace-mq-net
volumes:
    mqvolume:
networks:
  ace-mq-net:
   driver: bridge

When I raise up the environment, I deploy a MQ Policy on ACE container with the follow configuration:
<policies>
  <policy policyType="MQEndpoint" policyName="MQ_DEV" policyTemplate="MQEndpoint">
    <connection>CLIENT</connection>
    <destinationQueueManagerName>MQDEV</destinationQueueManagerName>
    <queueManagerHostname>host.docker.internal</queueManagerHostname>
    <listenerPortNumber>1414</listenerPortNumber>
    <channelName>DEV.ADMIN.SVRCONN</channelName>
    <securityIdentity>DSN_MQDEV</securityIdentity>
    <useSSL>false</useSSL>
    <SSLPeerName></SSLPeerName>
    <SSLCipherSpec></SSLCipherSpec>
    <SSLCertificateLabel></SSLCertificateLabel>
    <reconnectOption>default</reconnectOption>
    <CCDTUrl></CCDTUrl>
    <MQApplName></MQApplName>
  </policy>
</policies>

After it, I set de DSN Configuration using the following command on the ace container:
. /opt/ibm/ace-12/server/bin/mqsiprofile
mqsisetdbparms -w /home/aceuser/ace-server/ -n mq::DSN_MQDEV -u admin -p passw0rd

And I modified the server.conf.yaml to update the remotequeuemanager configuration (line 25 of server.conf.yaml)
remoteDefaultQueueManager: '{MQ_POLICY}:MQ_DEV'

and restart de container where ACE is running, but when the container restarted, the logs show the following:
Failed to make a client connection to queue manager 'MQ DEV' using hostname 'host.docker.internal' on port '1414': MQCC=2; MQRC=2012.
I've been looking in the documentation about the MQRC 2012, but is not clearly about what I will be doing wrong.
Someone did that configuration before?

Sorry, I'm not sure what to suggest.  We've not done any testing with Docker Swarm.  Given that MQ return code 2012 relates to an environment error in the client application, I think you might have better luck with contacting the ACE team.


Languages support

Hi,
Are you by any chance working on a multiple language support?
I've tried to translate the months and days of week to pt-BR, but found no option to do that on documentation.
Looking at the repo, I see that on 'src/constants/index.ts' there is a LANGUAGE variable being passed as "en" wich is the parameter of a language picker function.
Maybe this could be user defined instead of hardcoded?
If possible and in case I qualify, let me know if I can contribute on that.

you can use i18n like:
<DatePicker
    i18n="pt-BR"
    displayFormat="DD/MM/YYYY"
    ...
/>


Added LinearSearch.py

Added LinearSearch.py (Searching/Python/LinearSearch.py)
Kindly add the hacktoberfest-accepted label and then merge the pull request.
Thank you, Happy Hactober :)

Thanks for your contribution!


Create avl.c

This adds AVL TREE  algorithms problem in C.
Closes: #585

Thanks for contributing.


chore: bump rust version in ci to 1.73.0

Summary
bump rust version in ci to 1.73.0
Background
required for #579; had to bump penumbra deps, which bumped libp2p, which requires rust >=1.73.0
Changes

bump rust version in ci to 1.73.0

We should update the docker images as well probably

This change and the bump to prost/prost-build 0.12 in #579 is currently blocked on protoc-gen-prost still being on prost 0.11.

@SuperFluffy okay, should i merge this PR into my IBC branch for now then? i figured the rust version bump would be separate enough for its own PR but either way is fine with me!

Closing this in favor of #581 (move away from buf) and #582 (bump all dependencies)
@noot these two should unblock #579