Modulo behaves incorrectly for differing Exp values

The signature of impl Rem for Fix suggests that the two operands can have different Exp values, but their implementation is only correct if they have the same Exp value.
For example:
assert_eq(Megi::new(1) % Kibi::new(1022), 2)
This should evaluate 1024Ki % 1022Ki and get 2Ki, or at least 1Mi % 0Mi and get 0Mi, but it currently evaluates 1 % 1022 and gets 1.

Of course just restricting the impl to equal Exp's avoids an implicit conversion, which seems like a design goal here?

Oops, didn't think that one through properly.


Only matching whole words despite setting :using => {:tsearch => {:prefix => true}}

I have a Reference model:
class Reference < ActiveRecord::Base
  include PgSearch
  multisearchable :against => [:source_text, :citation], :using => {:tsearch => {:prefix => true}, :ignoring => :accent}
end

A 9.x version of postgres:
$ psql --version
psql (PostgreSQL) 9.2.2

And a rebuilt index:
pry(main)> PgSearch::Multisearch.rebuild(Reference)

When I search on whole words, like "lorem ipsum", I get search results, but when I search on partial words, like "lore", I get no results. Why? And how can I fix this?

Is this still true in 2024?


Create FUNDING.yml

Add SnoCo Makers as funding base.

  Or else the GUI is so badly designed that I didn't see how to do it.  So we won't have a funding image.


Favicon Missing for Under-the-hood-ReactJS

There is no favicon for Under-the-hood-ReactJs website.

@Bogdan-Lyashenko can you please give me the chance to create one. Thanks!


All observations are in the same group?? Please help!!

I'm trying to run your script but I get an error. I assume it has something to do with my mapping file but I am not sure how I need to fix it.
Also I don't really have time points in my data. All I want to see is there a differential abundance of OTUs between sites. My group significance data from QIIME suggest there is but I'd like to see this visualized in Lefse. Please help!!! Thanks.
/macqiime/anaconda/lib/python2.7/site-packages/rpy2/rinterface/init.py:186: RRuntimeWarning: Error in kruskal.test.default(c(0, 25.0400641025915, 0, 0, 0, 0, 0, 0,  :
all observations are in the same group
warnings.warn(x, RRuntimeWarning)
Traceback (most recent call last):
File "/macqiime/anaconda/bin/run_lefse.py", line 67, in
kw_ok,pv = test_kw_r(cls,feat_values,params['anova_alpha'],sorted(cls.keys()))
File "/macqiime/anaconda/bin/lefse.py", line 59, in test_kw_r
kw_res = robjects.r('kruskal.test('+fo+',)$p.value')
File "/macqiime/anaconda/lib/python2.7/site-packages/rpy2/robjects/init.py", line 362, in call
res = self.eval(p)
File "/macqiime/anaconda/lib/python2.7/site-packages/rpy2/robjects/functions.py", line 178, in call
return super(SignatureTranslatedFunction, self).call(*args, **kwargs)
File "/macqiime/anaconda/lib/python2.7/site-packages/rpy2/robjects/functions.py", line 106, in call
res = super(Function, self).call(*new_args, **new_kwargs)
rpy2.rinterface.RRuntimeError: Error in kruskal.test.default(c(0, 25.0400641025915, 0, 0, 0, 0, 0, 0,  :
all observations are in the same group
Traceback (most recent call last):
File "/macqiime/anaconda/bin/plot_cladogram.py", line 345, in
clad_tree = read_data(params['input_file'],params)
File "/macqiime/anaconda/bin/plot_cladogram.py", line 105, in read_data
with open(input_file, 'r') as inp:
IOError: [Errno 2] No such file or directory: 'test//lefse_output/run_lefse/Third.txt'
map_gut_final6.txt

Hey @slvrshot, can you please attach the text file located in the summarize_taxa/ folder and list the command you used?
Thanks,

map_gut_final6_L6.txt
koeken.py -i gut_15000_json.biom -m map_gut_final6.txt -cl Site -o test/ -sp Time -pc
gut_15000_json.biom.zip
I've uploaded the output from summarize_taxa.py: map_gut_final6_L6.txt
I've also included the original uncollapsed .biom file
Thanks!!!

Hey @slvrshot, so it looks like you are getting this error because each time the program splits the table by "Time", there is only one class of "Sites" in the table.
But if I understand correctly, you would like to just see if there is a difference between all 4 "Sites"?  In that case you can bypass the splitting part of the program by adding a new column in your mapping file that has the same value for each sample ( map_gut_final6_fixed.txt ) and then select that column name as your --split variable.  This will cause the program to include all the samples in the comparison because each sample has the same level.
So the full command would be:
koeken.py -i gut_15000_json.biom -o test/ -m map_gut_final6_fixed.txt --split Level -cl Site -pc

In the near future, I'm going to be updating the program dramatically and adding options like these to skip the split and just do a simple single comparison.
Hope this helps!

Thanks!!!!

Hi all,
I am also experiencing this same issue. I cant understand what formatting error I am doing wrong.
Would it be possible for you to help? I am very new to LEfSe, so my apologies if it is a very minor/obvious fix!
thanks in advance!
Lefse_ASV_PIGLETS.txt


Updated docs link to point to docs.rs

The documentation is now out of date with the recent 0.9.0 update, so I updated the readme to point to the most up-to-date version on docs.rs

yes, I forgot to update it... thanks!


preventDefault for the un-zoom button

https://github.com/rpearce/react-medium-image-zoom/blob/4ad2a9ceebdbdf247f388c69190f07b90cfa4d71/source/Controlled.tsx#L260
here we need to preventDefault, otherwise it causes un expected behaviour if the zoom component it self is inside a dialog.

@kayvaninvemo do you have time to put an example into a CodeSandbox that I can test with?

@kayvaninvemo I unfortunately don't yet understand what the problem is. If you can help me understand it with a demo, that would be helpful.

@rpearce
try here: https://stackblitz.com/edit/vitejs-vite-nddcft?file=src%2FApp.tsx

click button to open dialog
click image in dialog to open zoomed image
click the zoomed image

expect: only exit the zommed state, but keep dialog open
actual: not only exit the zoomed state, but also exit modal

@tjx666 this is exactly my issue. I did a workaround here
      onClose={(e: any) => {
        if (e.target?.id?.match(/rmiz-modal-.*/)) {
          return;
        }
        handleClose();
      }}

@tjx666 @kayvaninvemo Got it! Will fix. Many thanks for y'all's patience and sharing info.

Well, I thought this would be fixed in<EMAIL_ADDRESS>but I went back to that stackblitz, updated the package.json, re-installed, and gave it a whirl, but no difference.
Could one of y'all give this a try for me? It's not impossible @mui/material is doing something unexpected.

@djaffer This was not the case for me when I tested with a plain dialog element. Are you also using @mui/material?

At least for onClose and with MUI, this should now be resolved in<EMAIL_ADDRESS>Thanks for your patience!


add support for in row cells

I've used this library. And there is a reqirement for me to create table row like this:

Here is the sample code:
  val aConfig = List(
    ColumnConfig[ShuyunEvent](name = "Event ID", _.id),
    ColumnConfig[ShuyunEvent](name = "Application name", _.application),
    ColumnConfig[ShuyunEvent](name = "Event name", _.name),
    ColumnConfig[ShuyunEvent](name = "Event type", event => EventType.toFrontendString(event.eventType)),
    ColumnConfig[ShuyunEvent](name = "Tag name", _ => "", rowSeq = Some(event => event.tags.map(t => vdomNodeFromString(t.tagName)))),
    ColumnConfig[ShuyunEvent](name = "Tag type", _ => "", rowSeq = Some(event => event.tags.map(t => vdomNodeFromString(t.tagType.toString))))
  )

  class EventTableBackend($: BackendScope[Unit, Unit]) {
    val shuyunEvents = Seq(
      ShuyunEvent("1", "test", "View Commodity Page", EventType.PageView,
        List(
          ShuyunMetaTag("1", "Commodity Name", TagType.`String`),
          ShuyunMetaTag("1", "Commodity ID", TagType.`String`),
          ShuyunMetaTag("1", "Commodity Price", TagType.`Double`)

        ), CollectionTiming.PageLoaded, isActive = true)
    )

    def render = {
      <.div(
        BasicStyle.container,
        ReactTable(
          data = shuyunEvents,
          configs = aConfig
        )())
    }
  }

@rleibman OK, thank you. By the way, when will 1.1.0 be released? I'm looking forward it updates to scalajs-react 1.2.0 :)

We're working on it. I think the code is ready, but we're in the process of getting a sonatype ticket so we can deploy it with the new org.


Update package.json to contain repository field

The package.json file for node-recaptcha is missing the repository field even though it obviously have a respository. Could this be done by @mirhampt ?
This would fix the warning that comes up everytime you do something with the npm in a directory where node-recaptcha is installed.

+1

Fixed in my pull request #15

Merged and released as v1.2.1 on npm. Thanks!


exposed IsEqualCompressingWhiteSpace.string

exposed IsEqualCompressingWhiteSpace.string in protected getString in order to facilitate use in subclasses

@sf105 Maybe you didn't notice this since it's open for some time without a comment.

I'm curious to understand your use cases here. Do you have some subclasses that require breaking the encapsulation? Can you give an example?

@krichter722 not sure if this will work with Java 9+ and modules, but will have a look at getting merged

Going to try and kick start hamcrest, so if you want to get it merged, please rebase from the branch v2.3-candidates.
Still trying to understand how has permissions to perform a release.

Not really necessary.


Add extra Event model accessors

Description

There are a number of pieces of data that will need to be displayed on both the event index, as well as the event details page.
This data includes:

Event date (single date or range)
Event Capacity (total seats available)
Amount of registered users (# of session registrations)
Total spots available for an event (sum of all open seats)

See images for usage / location

Possible Implementation

Add accessors to event for each of these items. add the added accessors to the $appends property on the Event Model.

Event date --> pluck all start times from event sessions sorted by ascending, if it spans multiple days, generate a date range (Jan 1 - Jan 3), otherwise just return the day the sessions are on.
Event Capacity --> pluck seats from event sessions, take sum
Total spots available for event --> pluck open_seats accessor, take sum
Amount of registered users --> subtract event capacity and available seats values

Out of scope

N/a
Requirements / Restrictions

N/a

Hey team! Please add your planning poker estimate with ZenHub @bcobo341 @JasonGadoury @m-triassi @RobertoNittolo


sslsigalgs test fails on NonStop at master

This is a new breakage on our NonStop build at commit ffed597882baf2f07274e7eaa8f3c4fa9fa74ac1.
70-test_sslsigalgs.t ....................
# The results of this test will end up in test-runs/test_sslsigalgs
Proxy started on port [::1]:61174
Server command: ../../util/wrap.pl ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256
Engine "ossltest" set.
Using default temp DH parameters
ACCEPT [::1]:61945
Server responds on [::1]:61945
Client command: ../../util/wrap.pl ../../apps/openssl s_client -max_protocol TLSv1.3 -engine ossltest -connect [::1]:61174 -servername localhost
Engine "ossltest" set.
Connection opened
Received client packet
Packet length = 317
Processing flight 0
 Record 1 (client -> server)
  Content type: HANDSHAKE
  Version: TLS1.0
  Length: 312
  Message type: ClientHello
  Message Length: 308
    Client Version:771
    Session ID Len:32
    Ciphersuite len:62
    Compression Method Len:1
    Extensions Len:173

Forwarded packet length = 317

Received server packet
Packet length = 1349
Processing flight 1
 Record 1 (server -> client)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 122
  Message type: ServerHello
  Message Length: 118
    Server Version:771
    Session ID Len:32
    Ciphersuite:4865
    Compression Method:0
    Extensions Len:46
 Record 2 (server -> client)
  Content type: CCS
  Version: TLS1.2
  Length: 1
 Record 3 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 23
  Inner content type: HANDSHAKE
  Message type: EncryptedExtensions
  Message Length: 2
    Extensions Len:0
 Record 4 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 839
  Inner content type: HANDSHAKE
  Message type: Certificate
  Message Length: 818
    Context:
    Certificate List Len:814
    Certificate Len:809
    Extensions Len:0
 Record 5 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 281
  Inner content type: HANDSHAKE
  Message type: CertificateVerify
  Message Length: 260
    SigAlg:2052
    Signature Len:256
 Record 6 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 53
  Inner content type: HANDSHAKE
  Message type: Finished
  Message Length: 32

Forwarded packet length = 1349

depth=0 CN=server.example
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN=server.example
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN=server.example
verify return:1
Received client packet
Packet length = 64
Processing flight 2
 Record 1 (client -> server)
  Content type: CCS
  Version: TLS1.2
Connecting to ::1
CONNECTED(00000003)
---
Certificate chain
 0 s:CN=server.example
   i:CN=Root CA
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 14 22:29:46 2016 GMT; NotAfter: Jan 15 22:29:46 2116 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDJTCCAg2gAwIBAgIBAjANBgkqhkiG9w0BAQsFADASMRAwDgYDVQQDDAdSb290
IENBMCAXDTE2MDExNDIyMjk0NloYDzIxMTYwMTE1MjIyOTQ2WjAZMRcwFQYDVQQD
DA5zZXJ2ZXIuZXhhbXBsZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ANVdYGrf/GHuSKqMEUhDpW22Ul2qmEmxYZI1sfw6BCUMbXn/tNXJ6VwcO+Crs7h9
o95tveDd11q/FEcRQl6mgtBhwX/dE0bmCYUHDvLU/Bpk0gqtIKsga5bwrczEGVNV
3AEdpLPvirRJU12KBRzx3OFEv8XX4ncZV1yXC3XuiENxD8pswbSyUKd3RmxYDxG/
8XYkWq45QrdRZynh0FUwbxfkkeqt+CjCQ2+iZKn7nZiSYkg+6w1PgkqK/z9y7pa1
rqHBmLrvfZB1bf9aUp6r9cB+0IdD24UHBw99OHr90dPuZR3T6jlqhzfuStPgDW71
cKzCvfFu85KVXqnwoWWVk40CAwEAAaN9MHswHQYDVR0OBBYEFMDnhL/oWSczELBS
T1FSLwbWwHrNMB8GA1UdIwQYMBaAFHB/Lq6DaFmYBCMqzes+F80k3QFJMAkGA1Ud
EwQCMAAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwGQYDVR0RBBIwEIIOc2VydmVyLmV4
YW1wbGUwDQYJKoZIhvcNAQELBQADggEBAHvTBEN1ig8RrsT716Ginv4gGNX0LzGI
RrZ1jO7lm5emuaPNYJpGw0iX5Zdo91qGNXPZaZ75X3S55pQTActq3OPEBOll2pyk
iyjz+Zp/v5cfRZLlBbFW5gv2R94eibYr4U3fSn4B0yPcl4xH/l/HzJhGDsSDW8qK
8VIJvmvsPwmL0JMCv+FR59F+NFYZdND/KCXet59WUpF9ICmFCoBEX3EyJXEPwhbi
X2sdPzJbCjx0HLli8e0HUKNttLQxCsBTRGo6iISLLamwN47mGDa9miBADwGSiz2q
YeeuLO02zToHhnQ6KbPXOrQAqcL1kngO4g+j/ru+4AZThFkdkGnltvk=
-----END CERTIFICATE-----
subject=CN=server.example
issuer=CN=Root CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1349 bytes and written 381 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---
  Length: 1
 Record 2 (client -> server)
  Content type: APPLICATION DATA
DONE
  Version: TLS1.2
  Length: 53
  Inner content type: HANDSHAKE
  Message type: Finished
  Message Length: 32

Forwarded packet length = 64

Received client packet
Packet length = 50
Processing flight 2
 Record 1 (client -> server)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 21
  Inner content type: APPLICATION DATA
  [ENCRYPTED APPLICATION DATA]
  [test]
 Record 2 (client -> server)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 19
  Inner content type: ALERT
  [1, 0]

Forwarded packet length = 50

Received server packet
Packet length = 478
Processing flight 3
 Record 1 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 234
  Inner content type: HANDSHAKE
  Message type: NewSessionTicket
  Message Length: 213
 Record 2 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 234
  Inner content type: HANDSHAKE
  Message type: NewSessionTicket
  Message Length: 213

Forwarded packet length = 478

Received server packet
Packet length = 27
Processing flight 3
 Record 1 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 22
  Inner content type: APPLICATION DATA
  [ENCRYPTED APPLICATION DATA]
  [tset
]

Forwarded packet length = 27

Received server packet
Packet length = 24
Processing flight 3
 Record 1 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 19
  Inner content type: ALERT
  [1, 0]

Forwarded packet length = 24

Connection closed
Waiting for 'perl -ne print' process to close: 385876017...
New session added to external cache
New session added to external cache
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Client cipher list: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Ciphersuite: TLS_AES_128_GCM_SHA256
Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224:DSA+SHA224:DSA+SHA256:DSA+SHA384:DSA+SHA512
No peer certificate or raw public key
Supported groups: x25519:secp256r1:x448:secp521r1:secp384r1:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192
CONNECTION CLOSED
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   1 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   1 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (20480 allowed)
Waiting for s_server process to close:<PHONE_NUMBER>...
Waiting for s_client process to close: 436207709...
1..26
ok 1 - Default sigalgs
Server command: ../../util/wrap.pl ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256
Engine "ossltest" set.
Using default temp DH parameters
ACCEPT [::1]:61890
Server responds on [::1]:61890
Client command: ../../util/wrap.pl ../../apps/openssl s_client -max_protocol TLSv1.3 -engine ossltest -connect [::1]:61174 -servername localhost
Engine "ossltest" set.
Connection opened
Received client packet
Packet length = 317
Processing flight 0
 Record 1 (client -> server)
  Content type: HANDSHAKE
  Version: TLS1.0
  Length: 312
  Message type: ClientHello
  Message Length: 308
    Client Version:771
    Session ID Len:32
    Ciphersuite len:62
    Compression Method Len:1
    Extensions Len:173

Forwarded packet length = 265

Received server packet
Packet length = 7
Processing flight 1
 Record 1 (server -> client)
  Content type: ALERT
  Version: TLS1.2
  Length: 2
  [2, 109]

Forwarded packet length = 7

00000000:error:0A000455:SSL routines:ssl3_read_bytes:tlsv13 alert missing extension:/home/jenkinsbuild/.jenkins/workspace/OpenSSL-3.3_Monitor/ssl/record/rec_layer_s3.c:861:SSL alert number 109
Connecting to ::1
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 317 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
Connection closed
Waiting for 'perl -ne print' process to close: 436207665...
CONNECTION FAILURE
00000000:error:0A000070:SSL routines:final_sig_algs:missing sigalgs extension:/home/jenkinsbuild/.jenkins/workspace/OpenSSL-3.3_Monitor/ssl/statem/extensions.c:1342:
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   1 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   0 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (20480 allowed)
Waiting for s_server process to close: 452984925...
Waiting for s_client process to close:<PHONE_NUMBER>...
ok 2 - No TLSv1.3 sigalgs
Server command: ../../util/wrap.pl ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256
Engine "ossltest" set.
Using default temp DH parameters
ACCEPT [::1]:61648
Server responds on [::1]:61648
Client command: ../../util/wrap.pl ../../apps/openssl s_client -max_protocol TLSv1.3 -engine ossltest -connect [::1]:61174 -servername localhost
Engine "ossltest" set.
Connection opened
Received client packet
Packet length = 317
Processing flight 0
 Record 1 (client -> server)
  Content type: HANDSHAKE
  Version: TLS1.0
  Length: 312
  Message type: ClientHello
  Message Length: 308
    Client Version:771
    Session ID Len:32
    Ciphersuite len:62
    Compression Method Len:1
    Extensions Len:173

Forwarded packet length = 271

Received server packet
Packet length = 7
Processing flight 1
 Record 1 (server -> client)
  Content type: ALERT
  Version: TLS1.2
  Length: 2
  [2, 50]

Forwarded packet length = 7

00000000:error:0A00041A:SSL routines:ssl3_read_bytes:tlsv1 alert decode error:/home/jenkinsbuild/.jenkins/workspace/OpenSSL-3.3_Monitor/ssl/record/rec_layer_s3.c:861:SSL alert number 50
Connecting to ::1
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 317 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
Connection closed
Waiting for 'perl -ne print' process to close: 486539313...
CONNECTION FAILURE
00000000:error:0A00006E:SSL routines:tls_parse_ctos_sig_algs:bad extension:/home/jenkinsbuild/.jenkins/workspace/OpenSSL-3.3_Monitor/ssl/statem/extensions_srvr.c:301:
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   1 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   0 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (20480 allowed)
Waiting for s_server process to close:<PHONE_NUMBER>...
Waiting for s_client process to close:<PHONE_NUMBER>...
ok 3 - Empty TLSv1.3 sigalgs
Server command: ../../util/wrap.pl ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256
Engine "ossltest" set.
Using default temp DH parameters
ACCEPT [::1]:61149
Server responds on [::1]:61149
Client command: ../../util/wrap.pl ../../apps/openssl s_client -max_protocol TLSv1.3 -engine ossltest -connect [::1]:61174 -servername localhost
Engine "ossltest" set.
Connection opened
Received client packet
Packet length = 317
Processing flight 0
 Record 1 (client -> server)
  Content type: HANDSHAKE
  Version: TLS1.0
  Length: 312
  Message type: ClientHello
  Message Length: 308
    Client Version:771
    Session ID Len:32
    Ciphersuite len:62
    Compression Method Len:1
    Extensions Len:173

Forwarded packet length = 273

Received server packet
Packet length = 7
Processing flight 1
 Record 1 (server -> client)
  Content type: ALERT
  Version: TLS1.2
  Length: 2
  [2, 40]

Forwarded packet length = 7

00000000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:/home/jenkinsbuild/.jenkins/workspace/OpenSSL-3.3_Monitor/ssl/record/rec_layer_s3.c:861:SSL alert number 40
Connecting to ::1
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 317 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
Connection closed
Waiting for 'perl -ne print' process to close: 536870961...
CONNECTION FAILURE
00000000:error:0A000178:SSL routines:tls1_set_server_sigalgs:no shared signature algorithms:/home/jenkinsbuild/.jenkins/workspace/OpenSSL-3.3_Monitor/ssl/t1_lib.c:2160:
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   1 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   0 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (20480 allowed)
Waiting for s_server process to close:<PHONE_NUMBER>...
Waiting for s_client process to close: 520093789...
ok 4 - No known TLSv1.3 sigalgs
Server command: ../../util/wrap.pl ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256
Engine "ossltest" set.
Using default temp DH parameters
ACCEPT [::1]:61156
Server responds on [::1]:61156
Client command: ../../util/wrap.pl ../../apps/openssl s_client -max_protocol TLSv1.3 -engine ossltest -connect [::1]:61174 -servername localhost
Engine "ossltest" set.
Connection opened
Received client packet
Packet length = 317
Processing flight 0
 Record 1 (client -> server)
  Content type: HANDSHAKE
  Version: TLS1.0
  Length: 312
  Message type: ClientHello
  Message Length: 308
    Client Version:771
    Session ID Len:32
    Ciphersuite len:62
    Compression Method Len:1
    Extensions Len:173

Forwarded packet length = 273

Received server packet
Packet length = 7
Processing flight 1
 Record 1 (server -> client)
  Content type: ALERT
  Version: TLS1.2
  Length: 2
  [2, 40]

Forwarded packet length = 7

00000000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:/home/jenkinsbuild/.jenkins/workspace/OpenSSL-3.3_Monitor/ssl/record/rec_layer_s3.c:861:SSL alert number 40
Connecting to ::1
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 317 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
Connection closed
Waiting for 'perl -ne print' process to close: 587202609...
CONNECTION FAILURE
00000000:error:0A000076:SSL routines:tls_choose_sigalg:no suitable signature algorithm:/home/jenkinsbuild/.jenkins/workspace/OpenSSL-3.3_Monitor/ssl/t1_lib.c:3726:
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   1 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   0 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (20480 allowed)
Waiting for s_server process to close: 536871005...
Waiting for s_client process to close:<PHONE_NUMBER>...
ok 5 - No PSS TLSv1.3 sigalgs
Server command: ../../util/wrap.pl ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256
Engine "ossltest" set.
Using default temp DH parameters
ACCEPT [::1]:61239
Server responds on [::1]:61239
Client command: ../../util/wrap.pl ../../apps/openssl s_client -max_protocol TLSv1.3 -engine ossltest -connect [::1]:61174 -servername localhost
Engine "ossltest" set.
Connection opened
Received client packet
Packet length = 317
Processing flight 0
 Record 1 (client -> server)
  Content type: HANDSHAKE
  Version: TLS1.0
  Length: 312
  Message type: ClientHello
  Message Length: 308
    Client Version:771
    Session ID Len:32
    Ciphersuite len:62
    Compression Method Len:1
    Extensions Len:173

Forwarded packet length = 273

Received server packet
Packet length = 1349
Processing flight 1
 Record 1 (server -> client)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 122
  Message type: ServerHello
  Message Length: 118
    Server Version:771
    Session ID Len:32
    Ciphersuite:4865
    Compression Method:0
    Extensions Len:46
 Record 2 (server -> client)
  Content type: CCS
  Version: TLS1.2
  Length: 1
 Record 3 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 23
  Inner content type: HANDSHAKE
  Message type: EncryptedExtensions
  Message Length: 2
    Extensions Len:0
 Record 4 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 839
  Inner content type: HANDSHAKE
  Message type: Certificate
  Message Length: 818
    Context:
    Certificate List Len:814
    Certificate Len:809
    Extensions Len:0
 Record 5 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 281
  Inner content type: HANDSHAKE
  Message type: CertificateVerify
  Message Length: 260
    SigAlg:2052
    Signature Len:256
 Record 6 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 53
  Inner content type: HANDSHAKE
  Message type: Finished
  Message Length: 32

Forwarded packet length = 1349

depth=0 CN=server.example
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN=server.example
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN=server.example
verify return:1
Received client packet
Packet length = 64
Processing flight 2
 Record 1 (client -> server)
Connecting to ::1
CONNECTED(00000003)
---
Certificate chain
 0 s:CN=server.example
   i:CN=Root CA
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 14 22:29:46 2016 GMT; NotAfter: Jan 15 22:29:46 2116 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDJTCCAg2gAwIBAgIBAjANBgkqhkiG9w0BAQsFADASMRAwDgYDVQQDDAdSb290
IENBMCAXDTE2MDExNDIyMjk0NloYDzIxMTYwMTE1MjIyOTQ2WjAZMRcwFQYDVQQD
DA5zZXJ2ZXIuZXhhbXBsZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ANVdYGrf/GHuSKqMEUhDpW22Ul2qmEmxYZI1sfw6BCUMbXn/tNXJ6VwcO+Crs7h9
o95tveDd11q/FEcRQl6mgtBhwX/dE0bmCYUHDvLU/Bpk0gqtIKsga5bwrczEGVNV
3AEdpLPvirRJU12KBRzx3OFEv8XX4ncZV1yXC3XuiENxD8pswbSyUKd3RmxYDxG/
8XYkWq45QrdRZynh0FUwbxfkkeqt+CjCQ2+iZKn7nZiSYkg+6w1PgkqK/z9y7pa1
rqHBmLrvfZB1bf9aUp6r9cB+0IdD24UHBw99OHr90dPuZR3T6jlqhzfuStPgDW71
cKzCvfFu85KVXqnwoWWVk40CAwEAAaN9MHswHQYDVR0OBBYEFMDnhL/oWSczELBS
T1FSLwbWwHrNMB8GA1UdIwQYMBaAFHB/Lq6DaFmYBCMqzes+F80k3QFJMAkGA1Ud
EwQCMAAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwGQYDVR0RBBIwEIIOc2VydmVyLmV4
YW1wbGUwDQYJKoZIhvcNAQELBQADggEBAHvTBEN1ig8RrsT716Ginv4gGNX0LzGI
RrZ1jO7lm5emuaPNYJpGw0iX5Zdo91qGNXPZaZ75X3S55pQTActq3OPEBOll2pyk
iyjz+Zp/v5cfRZLlBbFW5gv2R94eibYr4U3fSn4B0yPcl4xH/l/HzJhGDsSDW8qK
8VIJvmvsPwmL0JMCv+FR59F+NFYZdND/KCXet59WUpF9ICmFCoBEX3EyJXEPwhbi
X2sdPzJbCjx0HLli8e0HUKNttLQxCsBTRGo6iISLLamwN47mGDa9miBADwGSiz2q
YeeuLO02zToHhnQ6KbPXOrQAqcL1kngO4g+j/ru+4AZThFkdkGnltvk=
-----END CERTIFICATE-----
subject=CN=server.example
issuer=CN=Root CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1349 bytes and written 381 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---
  Content type: CCS
  Version: TLS1.2
  Length: 1
 Record 2 (client -> server)
  Content type: APPLICATION DATA
DONE
  Version: TLS1.2
  Length: 53
  Inner content type: HANDSHAKE
  Message type: Finished
  Message Length: 32

Forwarded packet length = 64

Received client packet
Packet length = 50
Processing flight 2
 Record 1 (client -> server)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 21
  Inner content type: APPLICATION DATA
  [ENCRYPTED APPLICATION DATA]
  [test]
 Record 2 (client -> server)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 19
  Inner content type: ALERT
  [1, 0]

Forwarded packet length = 50

Received server packet
Packet length = 239
Processing flight 3
 Record 1 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 234
  Inner content type: HANDSHAKE
  Message type: NewSessionTicket
  Message Length: 213

Forwarded packet length = 239

Received server packet
Packet length = 239
Processing flight 3
 Record 1 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 234
  Inner content type: HANDSHAKE
  Message type: NewSessionTicket
  Message Length: 213

Forwarded packet length = 239

Received server packet
Packet length = 27
Processing flight 3
 Record 1 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 22
  Inner content type: APPLICATION DATA
  [ENCRYPTED APPLICATION DATA]
  [tset
]

Forwarded packet length = 27

Received server packet
Packet length = 24
Processing flight 3
 Record 1 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 19
  Inner content type: ALERT
  [1, 0]

Forwarded packet length = 24

Connection closed
Waiting for 'perl -ne print' process to close: 637534257...
New session added to external cache
New session added to external cache
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Client cipher list: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Ciphersuite: TLS_AES_128_GCM_SHA256
Signature Algorithms: RSA-PSS+SHA256
No peer certificate or raw public key
Supported groups: x25519:secp256r1:x448:secp521r1:secp384r1:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192
CONNECTION CLOSED
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   1 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   1 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (20480 allowed)
Waiting for s_server process to close:<PHONE_NUMBER>...
Waiting for s_client process to close:<PHONE_NUMBER>...
ok 6 - PSS only sigalgs in TLSv1.3
Server command: ../../util/wrap.pl ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256
Engine "ossltest" set.
Using default temp DH parameters
ACCEPT [::1]:61010
Server responds on [::1]:61010
Client command: ../../util/wrap.pl ../../apps/openssl s_client -max_protocol TLSv1.3 -engine ossltest -connect [::1]:61174 -servername localhost
Engine "ossltest" set.
Connection opened
Received client packet
Packet length = 317
Processing flight 0
 Record 1 (client -> server)
  Content type: HANDSHAKE
  Version: TLS1.0
  Length: 312
  Message type: ClientHello
  Message Length: 308
    Client Version:771
    Session ID Len:32
    Ciphersuite len:62
    Compression Method Len:1
    Extensions Len:173

Forwarded packet length = 317

Received server packet
Packet length = 1349
Processing flight 1
 Record 1 (server -> client)
  Content type: HANDSHAKE
  Version: TLS1.2
  Length: 122
  Message type: ServerHello
  Message Length: 118
    Server Version:771
    Session ID Len:32
    Ciphersuite:4865
    Compression Method:0
    Extensions Len:46
 Record 2 (server -> client)
  Content type: CCS
  Version: TLS1.2
  Length: 1
 Record 3 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 23
  Inner content type: HANDSHAKE
  Message type: EncryptedExtensions
  Message Length: 2
    Extensions Len:0
 Record 4 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 839
  Inner content type: HANDSHAKE
  Message type: Certificate
  Message Length: 818
    Context:
    Certificate List Len:814
    Certificate Len:809
    Extensions Len:0
 Record 5 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 281
  Inner content type: HANDSHAKE
  Message type: CertificateVerify
  Message Length: 260
    SigAlg:2052
    Signature Len:256
 Record 6 (server -> client)
  Content type: APPLICATION DATA
  Version: TLS1.2
  Length: 53
  Inner content type: HANDSHAKE
  Message type: Finished
  Message Length: 32

Forwarded packet length = 1349

depth=0 CN=server.example
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN=server.example
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN=server.example
verify return:1
00000000:error:0A000172:SSL routines:tls12_check_peer_sigalg:wrong signature type:/home/jenkinsbuild/.jenkins/workspace/OpenSSL-3.3_Monitor/ssl/t1_lib.c:1913:
Received client packet
Packet length = 7
Processing flight 2
 Record 1 (client -> server)
  Content type: ALERT
  Version: TLS1.2
  Length: 2
Connecting to ::1
CONNECTED(00000003)
---
Certificate chain
 0 s:CN=server.example
   i:CN=Root CA
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 14 22:29:46 2016 GMT; NotAfter: Jan 15 22:29:46 2116 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDJTCCAg2gAwIBAgIBAjANBgkqhkiG9w0BAQsFADASMRAwDgYDVQQDDAdSb290
IENBMCAXDTE2MDExNDIyMjk0NloYDzIxMTYwMTE1MjIyOTQ2WjAZMRcwFQYDVQQD
DA5zZXJ2ZXIuZXhhbXBsZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ANVdYGrf/GHuSKqMEUhDpW22Ul2qmEmxYZI1sfw6BCUMbXn/tNXJ6VwcO+Crs7h9
o95tveDd11q/FEcRQl6mgtBhwX/dE0bmCYUHDvLU/Bpk0gqtIKsga5bwrczEGVNV
3AEdpLPvirRJU12KBRzx3OFEv8XX4ncZV1yXC3XuiENxD8pswbSyUKd3RmxYDxG/
8XYkWq45QrdRZynh0FUwbxfkkeqt+CjCQ2+iZKn7nZiSYkg+6w1PgkqK/z9y7pa1
rqHBmLrvfZB1bf9aUp6r9cB+0IdD24UHBw99OHr90dPuZR3T6jlqhzfuStPgDW71
cKzCvfFu85KVXqnwoWWVk40CAwEAAaN9MHswHQYDVR0OBBYEFMDnhL/oWSczELBS
T1FSLwbWwHrNMB8GA1UdIwQYMBaAFHB/Lq6DaFmYBCMqzes+F80k3QFJMAkGA1Ud
EwQCMAAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwGQYDVR0RBBIwEIIOc2VydmVyLmV4
YW1wbGUwDQYJKoZIhvcNAQELBQADggEBAHvTBEN1ig8RrsT716Ginv4gGNX0LzGI
RrZ1jO7lm5emuaPNYJpGw0iX5Zdo91qGNXPZaZ75X3S55pQTActq3OPEBOll2pyk
iyjz+Zp/v5cfRZLlBbFW5gv2R94eibYr4U3fSn4B0yPcl4xH/l/HzJhGDsSDW8qK
8VIJvmvsPwmL0JMCv+FR59F+NFYZdND/KCXet59WUpF9ICmFCoBEX3EyJXEPwhbi
X2sdPzJbCjx0HLli8e0HUKNttLQxCsBTRGo6iISLLamwN47mGDa9miBADwGSiz2q
YeeuLO02zToHhnQ6KbPXOrQAqcL1kngO4g+j/ru+4AZThFkdkGnltvk=
-----END CERTIFICATE-----
subject=CN=server.example
issuer=CN=Root CA
---
No client certificate CA names sent
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1291 bytes and written 324 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---
  [2, 47]

Forwarded packet length = 7

Connection closed
Waiting for 'perl -ne print' process to close: 687865905...
CONNECTION FAILURE
00000000:error:0A000417:SSL routines:ssl3_read_bytes:ssl/tls alert illegal parameter:/home/jenkinsbuild/.jenkins/workspace/OpenSSL-3.3_Monitor/ssl/record/rec_layer_s3.c:861:SSL alert number 47
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   1 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   0 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (20480 allowed)
Waiting for s_server process to close:<PHONE_NUMBER>...
Waiting for s_client process to close:<PHONE_NUMBER>...
ok 7 - Mismatch between CertVerify sigalg and public key OID
Server command: ../../util/wrap.pl ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256
Engine "ossltest" set.
Using default temp DH parameters
00000000:error:80001012:system library:BIO_bind:Address already in use:/home/jenkinsbuild/.jenkins/workspace/OpenSSL-3.3_Monitor/crypto/bio/bio_sock2.c:240:calling bind()
00000000:error:10000075:BIO routines:BIO_bind:unable to bind socket:/home/jenkinsbuild/.jenkins/workspace/OpenSSL-3.3_Monitor/crypto/bio/bio_sock2.c:242:
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   0 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   0 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (20480 allowed)
Server responds on [::1]:61010
unable to connect: Connection refused
# Looks like your test exited with 4127 just after 7.
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 19/26 subtests

Hmm... is that reproducible failure? It seems like the server was just not able to bind a socket.

Hmm... is that reproducible failure? It seems like the server was just not able to bind a socket.

We had a failure in the IP stack during that period. I will recheck after I am certain everything is fine. Might be tomorrow.

Hmm... is that reproducible failure? It seems like the server was just not able to bind a socket.

This was transient. Thanks for looking into it, @t8m.


[api] Group CRUD

Enabling post/put/patch/delete on /api/groups
Refactored/re-using parse_ methods
Made role/tenant fetches RBAC aware
Added filters structure validation in model
Added specs

https://trello.com/c/wPzTtz4S/147-api-need-full-crud-on-api-groups

@imtayadeway @gtanzillo please review. Thanks.

:+1: Looks good!


feat: LVM support

Hi there,
I authored rlb so I can do LVM-snapshot based, mounted backups using Restic. This combines atomic backups with all the advantages of having the filesystem mounted; the backups are invoked by systemd timers and the service triggered by the timer is intentionally restricted from running when fstrim.service runs so as to avoid fstrim + dm-snapshot issues that I'd encountered a few times.
The advantage: Using lvm to create a mountable, atomic snapshot of a filesystem for backup means that all of the advantages restic gets (similar to what rsync gets) for reading not just a filesystem but the same filesystem it read previously are conferred to restic -- in particular, extremely fast and small snapshots, reading from cached pages on the underlying block device (dm-snapshot does that, it's really incredible) -- while also providing an atomic view of the snapshot.
Anyways, I'm working on implementing that here, using (in addition to what I have under rlb):

mount namespaces (using man 5 systemd.exec's PrivateMounts=on in the [Service] configuration part of the unit)
bind-mounting the subdirectory being backed up to the same directory within the mount-namespace
a few additional role variables describing the backup process.

Questions:

Are we OK restricting that functionality to systems using systemd?
Are we OK with the additional functionality and configuration options here?
Are we OK with making it clear that the filesystems this works on are restricted?

I'm going to guess the kernel is going to be unhappy finding out there are two nearly-identical (by UUID) BTRFS devices attached to it, for example, even when it doesn't have the same concerns with XFS or EXT4 -- so we'd probably want to restrict the use of LVM to backing-up subdirectories on those filesystems.

Would we prefer forcing the role administrator to be explicit with the details about the mountpath being backed up? (e.g. force them to provide the VG / LV name, how much snapshot space they want, etc).

bind-mounting the subdirectory being backed up to the same directory within the mount-namespace

This won't work for /, so perhaps instead, bind-mount somewhere so that Restic backs things up consistently (e.g. bind-mount everything to /_/).


OpenProtocolAttributes missing EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL

The OpenProtocolAttributes enum is currently missing a representation of the EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL value defined by UEFI. Without this, there doesn't seem to be a way to directly open a protocol from a specified handle non-exclusively. Some example code:
let boot_services = system_table.boot_services();

let search = SearchType::from_proto::<GraphicsOutput>();
let handle_buffer = boot_services.locate_handle_buffer(search)?;

for handle in handle_buffer.handles() {
    let params = OpenProtocolParams {
        handle: *handle,
        agent: image,
        controller: None
    };
    let attribs = unsafe { core::mem::transmute(1) };
    let gop = unsafe {
        boot_services.open_protocol::<GraphicsOutput>(params, attribs)?
    };

    let modeinfo = gop.current_mode_info();
    let (width, height) = modeinfo.resolution();
    uefi_services::println!("Graphics mode: {}x{}", width, height);
}

When attempting to open the GraphicsOutput protocol exclusively here, an error seems to be encountered, presumably either upon opening the protocol or somewhere in uefi_services::println!, so non-exclusivity seems to be required here. However, the code succeeds when performing the unsafe transmute from 1 (the value that EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL is defined to be).

You can use OpenProtocolAttributes::GetProtocol for that. See https://github.com/rust-osdev/uefi-rs/blob/main/uefi-test-runner/src/proto/console/gop.rs#L5 for an example of this in action.

It looks like GetProtocol will work in this circumstance so this ticket probably no longer affects me, although more generally GET_PROTOCOL  does have the caveat that any notification events created to be signaled upon a protocol being reinstalled will not be notified in the case of the protocol having been opened via GET_PROTOCOL -- only if it has been opened via BY_HANDLE_PROTOCOL, if I'm understanding the UEFI spec correctly.

I question whether anyone has been monitoring this issue, as the last comment was posted two years ago. Regardless, I would like to share my perspective.

only if it has been opened via BY_HANDLE_PROTOCOL, if I'm understanding the UEFI spec correctly.

As per the UEFI specification, BY_HANDLE_PROTOCOL is intended for use within the HandleProtocol() function of the EFI_BOOT_SERVICES. Its name suggests that it is meant to be employed specifically for this purpose.
In my view, the existance of attribute BY_HANDLE_PROTOCOL is intended to give the new API OpenProtocol() a chance to simulate the behavior of the OLD API HandleProtocol().
And the implemention in edk2 processes BY_HANDLE_PROTOCOL and GET_PROTOCOL the SAME way, meaning that there is no notification upon uninstallation/reinstallation of the protocol having been opened using BY_HANDLE_PROTOCOL.
Therefore, I concur with the comment for enum OpenProtocolAttributes:

// ByHandleProtocol (0x01) excluded because it is only intended to be
// used in an implementation of HandleProtocol.

I question whether anyone has been monitoring this issue

I wasn't actively paying attention to this issue, but I do I get email notifications for all comments in the repo :)
I'll go ahead and close, it seems like GetHandle is sufficient.


GitProvenance is very slow getting committers on a large Git history

What version of OpenRewrite are you using?

I am using

Maven plugin 5.32.0

What did you see instead?
After the following line of output
[INFO] Validating active recipes...

there is a delay of several minutes when I run locally. When I noticed this, I attached a profiler. The GitProvenance calculation of the committers takes forever. In the following screenshot that consumes around 7 minutes (after I noticed the delay, so add some minutes).

The git repo has 67K commits and 63K committed files (currently). I'm on Windows.
Maybe that information is useful when running on moderne.io infrastructure, but for local execution of most recipes that's probably not useful and should be improved.

Oh wow; picture really speaks volumes here; thanks for including that! The getCommitters(Repository) was added last year

https://github.com/openrewrite/rewrite/pull/3654

And is called from this group of methods.
https://github.com/openrewrite/rewrite/blob/58156584fa98e03cb9201b8f44739519f4e6f15e/rewrite-core/src/main/java/org/openrewrite/marker/GitProvenance.java#L146-L218
I agree with you that we should do something to improve performance here, or add a cut off past which we stop looking at committers; say a couple months. Either way thanks for calling this out!

Figured provide some more context: both the Maven plugin and Gradle plugin call the same method in openrewrite/rewrite to determine the GitProvenance. We're considering adding a 90 day committer history look back cut off to limit how many commits are evaluated while still having some committer history available to recipes. Not yet saying we'll definitely land on that, but figured give you that update such that you know we're working on it.

Thanks again @Bananeweizen ! Sam's had another look at it turns out that we're not just calling getCommitters(Repository) once, but once for each submodule(!). That then greatly inflates the time necessary, especially when there are a large number of modules. Sam will pick this up.

Likely fixed, or at least much improved in

https://github.com/openrewrite/rewrite-maven-plugin/commit/6abcb02653b101723b6ec4d454bd78be03ffc23d
https://github.com/openrewrite/rewrite-gradle-plugin/commit/a12a4403ebb0e668e37ff3fbe44b7ef328d33f9b

Thanks again for the reporting this issue; I hope you see similar improvements there, or else let us know!

@timtebeek much, much faster now. Haven't profiled, but the previous long pause surely isn't that long anymore.


How could I save all resources received into disk? Thanks for answering!

I want to use page.onResourceReceived event handler to save all resources received into disk, how could I accomplish this? Are there any methods to save all resources received into disk?

Thank you for submitting this ticket!
This issue tracker primarily serves as the tool to report and track bugs, defects, and development tasks.
For general question, code review request, build problem, or other related discussion, please post it to either:

the official PhantomJS users mailing-list
Stack Overflow (with phantomjs tag)

If you have not read it yet, please check also a few tips on Effective Q&A.


Use getter method instead of public variable in anchor contract

Post-Identity fix:
The node gets the anchor by directly accessing the public variable Commits. We should use the getter method for it. Commits will be private in the next version

AnchorRespositry was the only place where we used public variables in the contracts directly?


AnimationTree incorrectly transitions Skeletal Mesh animations if the AnimationPlayer is not the one inherited from the GLTF

Godot version
4.0-beta8
System information
Windows 10
Issue description
Consider the setup: a Skeletal Mesh with Animations, thus having an Inherited AnimationPlayer, and then you create another AnimationPlayer, with tracks that play animations from the inherited AnimationPlayer and/or additional custom tracks, such as CallMethod tracks.
Then if you call the animations from the custom AnimationPlayer with a State Machine AnimationTree, the AnimationTree does not interpolate the transitions between the animations correctly, creating either "stuck" frames or freezing the 1st animation before transitioning to the next one.
If you play animations from the inherited AnimationPlayer (the animations from the mesh, with nothing else), then the AnimationTree correctly transitions.
My current example

This machine has a "TurnOn" and a "Loop" animation, imported from Blender.
By adding the TurnOn animation to a custom AnimationPlayer, when transitioning to the Loop animation, something very strange happens with the engine (the gray one) which it gets stuck down ("crying engine") and then the looping animation does not play.
In the video, after showing the "crying engine", I show the loop animation which was supposed to play.
It can be hard to reproduce this, so my reproducible project mimics the issue using the same scenario (an engine with TurnOn and Loop animations).

https://user-images.githubusercontent.com/248383/206927925-d859c142-15f0-4af6-a668-031551a42f2b.mp4
Steps to reproduce

Import a skeletal mesh with at least two animations
Created an Inherited Scene from the Mesh
Add a script to the inherited scene and add any method for it
Add an AnimationTree and an AnimationPlayer
Create two animations in the AnimationPlayer

Animation 1 (ex: "TurnOn)":

Add an AnimationPlayback Track, and insert a key playing an animation from the inherited AnimationPlayer
Add a CallMethod track and call the method you added to the scene before

Animation 2 (ex: "Loop)":

Add an AnimationPlayback Track, and insert a key playing the other animation from the inherited AnimationPlayer

AnimationTree:

Add a State Machine as the root
Select the custom AnimationPlayer as the Anim Player param
Add a state for each one for the animations, being the animation with CallMethod the 1st one and then an At End, Auto Advance transition that transitions to the other one

Test:
If you test, the 1st animation "TurnOn":

Won't play
or will get stuck
or will cause bad interpolation to the next animation.

But if you manually play the custom "TurnOn" animation added before, it plays correctly. Then in the AnimationTree, it doesn't.
Minimal reproduction project
EventInAnimationDemo.zip

AnimationPlayerOriginal.tscn (red machine): the Inherited scene from the MachineMock.glb mesh, with an AnimationTree, using the original AnimationPlayer. This scene works correctly.
AnimationPlayerCustom.tscn: the inherited scene with the steps that lead to the bug. This scene has the scenario with custom animation player and that reproduces the steps I mentioned, and it doesn't work correctly.
RunTest.tscn: run to see it at runtime. The Red Machine correctly plays turn on then transitions to loop, but then it can't have custom animation tracks.

Probably a regression of #69336. It seems to be failing to get the first key. I forgot to apply fix #69588 to AnimationTrack, sorry.


GH-37209: [CI][Docs][MATLAB] Remove support for MATLAB_ARROW_INTERFACE flag from CMake build system and build new MATLAB Interface code by default

Rationale for this change
Now that the old Feather V1 code and associated build infrastructure has been removed (#37204), it makes sense to start building the new, experimental MATLAB Interface code by default (without needing to explicitly specify -D MATLAB_ARROW_INTERFACE=ON).
This pull request removes the MATLAB_ARROW_INTERFACE flag entirely, since setting it to OFF when we are building the MATLAB Interface code by default would essentially imply that no code should be built.
What changes are included in this PR?

Removed mention of MATLAB_ARROW_INTERFACE flag from MATLAB README.md.
Removed conditional check for MATLAB_ARROW_INTERFACE flag from MATLAB CMakeLists.txt.
Removed MATLAB_ARROW_INTERFACE flag from matlab_build.sh CI script.

Are these changes tested?
Yes.
The MATLAB Interface is building as expected by default on my Debian 11 machine.
Are there any user-facing changes?
Yes.

The experimental MATLAB Interface APIs will now be built by default without users explicitly specifying -D MATLAB_ARROW_INTERFACE=ON to cmake.
If users specify a value for MATLAB_ARROW_INTERFACE, the value will be ignored by the CMake build system.

Closes: #37209

FYI - @CurtHagenlocher / @westonpace - it looks like the "Dev / Source Release and Merge Script" CI workflow is failing. The logs mention C# and FlatBuffers. Could this be related to #35699?

FYI - @CurtHagenlocher / @westonpace - it looks like the "Dev / Source Release and Merge Script" CI workflow is failing. The logs mention C# and FlatBuffers. Could this be related to #35699?

Seems likely.  I'll take a look.

My mistake, I merged an old PR without thinking that I should probably rebase it first.  Fix incoming in https://github.com/apache/arrow/pull/37214


Auto-Fill Android SDK path with ANDROID_HOME environment variable

It'd be pretty nice to have.

Yeah, it would, hm... I'll have to see what steps I would need to do, but it shouldn't be too much.

I'm not sure if this is fixed for all machines, but I addressed this at least partially in September. The Android SDK path is loaded from Preferences if it has ever been set before, so this mainly matters on the first run (when Preferences are empty). I'm loading the ANDROID_SDK_ROOT variable, which is set by Android Studio in its current versions (last I checked), instead of ANDROID_HOME, which is not set by any current installers that I could find. If anyone still has issues with this, like a wildly incorrect path being used at the start or continually used on multiple runs, please comment and I can reopen.


Update hugging face notebook

add Colab link to hugging face and remove outputs

im not keen now on how we are loading blog content, as we are embedding on a very dense field that contains html. For simplicity, i think we should use the sample dataset that some of the examples used just so we avoid topics like chunking, html stripping. We can then provide a nice response example.

I do not mind changing the dataset, but the results will be mixed feelings.
The search with NLP works better with a bigger dataset. But, if the book is only for how to load the NLP model from hugging face, then OK.

closing this now that saarika has merged her eland improvements.


Preparing localization for all UI messages and russian localization

Preparing localization for all UI messages («trans», «blocktrans»)
Add russian localization for all these messages

Impressive @belonesox! Thank you for the contribution, will check this out properly soon.

@belonesox Could you delete the .mo files and add .mo to the git ignore please?
They're generated files & typically a generated file isn't committed to git.

OK, done, but there are different rules for these, and  I follow that
https://github.com/groveco/django-sql-explorer/blob/master/explorer/locale/zh_Hans/LC_MESSAGES/django.mo
included in your git, your setup.py missed compilemessages flow, and now for all who would install  django-sql-explorer from pip russian localization will not work out the box.

@belonesox in my experience, packages don't need to ship with mo files because the Django project using the app will define its supported languages and the person deploying the app runs compile messages which then creates the mo files.
One of the main packages I use in this circumstance being Django allauth.
I can certainly build the command into the release pipeline. That way they'd go into the pip package.

packages don't need to ship with mo files

Every python/django package should contain in WHL file compiled «mo-files». Usually, these files stored on git
https://github.com/django/django/tree/main/django/contrib/admin/locale/af/LC_MESSAGES

Theoretically, it possible to not store it (I cannot remember a project with such paradigm, just checked almost all my django deps wheels — and cannot find such project), but then setup.py should:

have big deps in setup_requires (big django staff) and provide build flow in setup.py for building these mo-files.
of course publish whl-builds in pypi with compiled mo-files.

because the Django project using the app will define its supported languages,  and the person deploying the app runs compile messages which then creates the mo files.

compilation «po → mo» (django_admin compilemessages) compiles '''all''' available language po-files, it does not depend of locales supported/selected by application.
If user run django_admin compilemessages, it compiles locale only for user application, not for django applications that use this app.

@belonesox Ah ok, if django stores it's mo files in git, then lets keep things consistent & do the same, if you don't mind?
Thanks for providing that extra info!

OK, return "mo" back.

Is something else need to merge this?

@belonesox I added some comments about the way you've added the translation tags. Feel free to share any thoughts or I could merge & then make changes myself.

I added some comments about the way you've added the translation tags

Sorry, I dont see them. There I should read these comments?

@belonesox I've released this is 2.3


[Bug] upgrade elasticsearch client jar due to cves

What happened
https://discuss.elastic.co/c/announcements/security-announcements/31
Not sure if all these issues relate just to elasticsearch server side - still feels like client jar should be upgraded just in case
Dependabot id recommending upgrade to at least the latest v6 jar - 6.8.23
What you expected to happen
n/a
How to reproduce
n/a
Environment
No response
InLong version
master
InLong Component
InLong Audit
Are you willing to submit PR?

[X] Yes, I am willing to submit a PR!

Code of Conduct

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

@pjfanning thanks for your contributions to security issues recently.
Do you know some tools or plugins which can scan all potential security issues for InLong? After that, we can add an action workflow  for future PRs, make it found before committing.

@dockerzhang I'm using dependabot - I'm not sure if you can add it to this project directly but in your github fork, you can go to the 'Security' tab and enable 'Dependabot alerts'. Within a few moments, you will see the same list of jar and npm issues I see in my fork.

@pjfanning thanks. 'Dependabot alerts maybe is only available for person repo, and there is CodeQL Analysis for the InLong project, i will add it later.


Help with Instructions

I am new to reactjs, I want to know how to install this in a form

你可以使用HTTP请求方式获取验证码图片。然后在前端获取到验证码之后。转Blob。然后再使用FileReader。然后获取到Base64的字符串。加到img的src属性里就好了

I am new to reactjs, I want to know how to install this in a form

You should just need  element in your form. It may look like,


[feature] Get  button update

What problem does this new feature solve?
@kacperoak  @ignaciosantise @quetool @svenvoskamp end of last week we iterated with @Ilja to add the stores button on desktop and make wallet mobile apps & extensions linked for users of this device too (full discussion here).
Describe the solution you'd like
To support the app on 2 stores case we created an universal Get the app entry. Please update :pray::skin-tone-3:

@dianeben is the whole component pressable? or only the "Get >" button?

Has been implemented, so closing


Not able to start strongswan's ipsec

Hi guys,
I was trying to start an ipsec connection from my client using strongswan, as my company uses a Strongswan Bastion Server hosted on AWS.
After installing it
$ sudo apt-get install strongswan

When I try to start it, I get this error message:
$ sudo ipsec start
Starting strongSwan 5.1.2 IPsec [starter]...
no netkey IPsec stack detected
no KLIPS IPsec stack detected
no known IPsec stack detected, ignoring!

Any idea what that could be?
Thanks in advance!

Hey, thanks for reporting this!  Unfortunately, IPSec is implemented partly using a kernel module (actually, several smaller kernel modules); WSL only provides a userspace environment, not a kernel-space environment, and I suspect that Microsoft hasn't yet provided implementations for all of the modules required by IPSec.
Windows's native IPSec support is usually pretty good, and WSL shares Windows's networking stack.  Could you just connect from Windows?  You might have to do some manual DNS configuration due to the issue tracked by #416 .

Hey @aseering,
thanks for your message! I wasn't aware of the models used by ipsec but your explanation definitely makes sense. Thanks a lot for that :)
RE. Windows's native IPSec, I actually tried it before but without any joy! Our server requires just a PSK and a username. It turned out that this kind of configuration doesn't work with Windows's IPSec client if you don't use a Certificate or, at least, this was an issue reported to a Strongswan email list found online.
I think I can live with it for now or will find at least a new solution. Thanks again


refactor: User common test cases for generated SAC store tests - GetMany

Description
A detailed explanation of the changes in your PR.
Feel free to remove this section if it is overkill for your PR, and the title of your PR is sufficiently descriptive.
Checklist

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

If any of these don't apply, please comment below.
Testing Performed
TODO(replace-me)
Use this space to explain how you tested your PR, or, if you didn't test it, why
you did not do so. Valid reasons include, for example, "CI is sufficient",
"No testable changes". Feel free to attach JSON snippets, curl commands,
screenshots.
In addition to reviewing your code, reviewers must also review your testing
instructions and make sure they are sufficient.

Current dependencies on/for this PR:

master

PR #6895

PR #6992

PR #7056   👈

PR #7057

PR #6993

PR #6923

PR #6924

This comment was auto-generated by Graphite.


darwin.libiconv: 50 -> 99 and move to pkgs/by-name

Description of changes
This is another attempt at https://github.com/NixOS/nixpkgs/pull/299613. The reasoning behind https://github.com/NixOS/nixpkgs/pull/238993 turned out to be mistaken. In the time between that PR and today, Apple has made several source releases. As it turns out, they switched their libiconv implementation from GNU libiconv to the implementation in FreeBSD’s libc. Updating libiconv proved to be non-trivial for a few reasons.

Upstream bugs. Apple’s implementation had bugs that caused libarchive test failures (leading to my adding a test case as I was working on diagnosing before a source release on Monday included a fix);
Build system issues. xcbuild cannot build libiconv correctly. The install names are a mess. It doesn’t handle tests are installation. Fixing would require relinking or hacking up the Xcode build project; and
Packaging ATF, Kyua, and Lutok. These are requirements for libiconv’s tests. They also mutually depend upon each other and have had releases in years. I opted to pin them to the same commits that FreeBSD’s ports does.

Fortunately, those issues were solvable and should not be an issue for updates going forward. libiconv now has a test suite, and the work to make the other dependencies build should be a one time cost for packaging them. I built for both aarch64-darwin and x86_64-darwin, and I confirmed that libarchive and libgit2 build and pass their tests.
The Linux builds were done on ATF, Kyua, and Lutok. I tried to build libiconv-darwin on Linux, but it failed. It may be possible with effort to make it build, but it seems rather pointless since glibc includes a libiconv implementation.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[x] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Building libgit2 and libarchive on macOS 10.13 fails because of kyua having a failing test:
utils/process/executor_pid_test:pid_wrap  ->  failed: Line 114: current != -1 no t met  [0.012s]

Building libgit2 and libarchive on macOS 10.13 fails because of kyua having a failing test:
utils/process/executor_pid_test:pid_wrap -> failed: Line 114: current != -1 no t met [0.012s]

If you try rebuilding it again (possibly just that drv), does it succeed? I noticed a handful of Kyua tests were flakey on x86_64-darwin, but I was hoping it was a local problem. I may also disable this whole chunk of tests on Darwin since it doesn’t support UF_UNNOUNLINK.

I fixed the conflicts and changed the libiconv tests to execute depending on whether a tests option was set (rather than whether it detected ATF).

Now the conflict should be fixed. I apparently fixed it on a different branch but not the one used for this PR.

While working on the cctools/ld64 update, I found a few issues with this PR that I want to fix. Temporarily setting this to draft until I can get those commits cherry-picked.

Build passed on aarch64-darwin before the last force push, x86_64-darwin is still going. Should I re-run again? I didn't see much change in the last force push.

Probably not. The last force push changed it to use the setup hooks from libiconvReal, but they’re identical to the existing hooks.

That was the intent but apparently it didn't. I'll kick off another build.
Saw you talking to infinisil about role.bash, did you end up finding a good resolution?

Saw you talking to infinisil about role.bash, did you end up finding a good resolution?

I passthru libiconvReal’s setupHook and use it in libiconv-darwin. libiconvReal isn’t in by-name, so it get to cheat for now. I’ll let whoever ends up moving it deal with how to handle role.bash if/when it’s moved there.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/darwin-updates-news/42249/11


Runtime Property to Handle BM & CIV use cases.

Tracked-On: OAM-105952

Jira issue not in ['bug','improvement'],
make sure jira issue is of type bug or improvement.


Game broken

When attempting to access this at https://eaton-dev-workshops.github.io/github-games-ViktorStamenov-eaton, I am getting a 404. This could be caused by a couple of things:

GitHub Pages needs to be enabled on the  branch. You can fix this in the repository settings.
The index.html file is incorrectly named inde.html. We will fix this together in class.

Can you fix the first bullet, please?

closes #1


LXC issue during verify-maas.yml

Do NOT include any confidential information, this issue will be created on a public repo
This section is completed by the issue reporter
On which version(s) do you encounter this issue?
Please provide the output to 'git describe --all' for  all deployments where you have confirmed it occurs.
What type of issue is this? Please tick the appropriate box.

[x] bug - existing functionality that does not work for you as documented
[ ] feature - new functionality that you would like to see added

What is the expected behavior?
The verify-maas playbook runs without issues.
What is actually happening?
With multi-node AIO and master, the loadbalancer1 node fails because lxc is not installed, similar to what was seen in https://github.com/rcbops/rpc-openstack/issues/2026.
TASK [Local MaaS Checks] *******************************************************
FAILED - RETRYING: TASK: Local MaaS Checks (5 retries left).
ok: [swift2]
ok: [swift1]
ok: [swift3]
ok: [logging1]
ok: [cinder2]
ok: [cinder1]
ok: [infra2]
ok: [infra1]
ok: [infra3]
ok: [compute1]
ok: [compute2]
FAILED - RETRYING: TASK: Local MaaS Checks (4 retries left).
FAILED - RETRYING: TASK: Local MaaS Checks (3 retries left).
FAILED - RETRYING: TASK: Local MaaS Checks (2 retries left).
FAILED - RETRYING: TASK: Local MaaS Checks (1 retries left).
fatal: [loadbalancer1]: FAILED! => {"changed": false, "cmd": " . /openstack/venvs/maas-r13.1.0rc1/bin/activate\n  /opt/rpc-openstack/scripts/rpc-maas-tool.py verify-local", "delta": "0:00:05.656338", "end": "2017-04-03 11:33:18.815656", "failed": true, "failed_when_result": true, "rc": 1, "start": "2017-04-03 11:33:13.159318", "stderr": "", "stdout": "The following metrics are required by alarms but not produced by any checks: set(['container_storage_percent_used_critical'])\nThe following checks failed to execute or didn't return 'okay' as their status: [('container_storage_check--omnamxp-1-4a64', 'Traceback (most recent call last):\\n  File \"/usr/lib/rackspace-monitoring-agent/plugins/container_storage_check.py\", line 21, in <module>\\n    import lxc\\nImportError: No module named lxc\\n')]", "stdout_lines": ["The following metrics are required by alarms but not produced by any checks: set(['container_storage_percent_used_critical'])", "The following checks failed to execute or didn't return 'okay' as their status: [('container_storage_check--omnamxp-1-4a64', 'Traceback (most recent call last):\\n  File \"/usr/lib/rackspace-monitoring-agent/plugins/container_storage_check.py\", line 21, in <module>\\n    import lxc\\nImportError: No module named lxc\\n')]"], "warnings": []}

https://rpc.jenkins.cit.rackspace.net/view/Multi-Node AIO/job/OnMetal_Multi_Node_AIO_master-xenial-periodic/1/execution/node/368/log/
https://rpc.jenkins.cit.rackspace.net/view/Multi-Node AIO/job/OnMetal_Multi_Node_AIO_master-trusty-periodic/1/execution/node/368/log/
What were you attempting to do when you encountered this error (give as much detail as possible)?
Created a multi-node AIO with either trusty or xenial against master.
How can we reproduce this issue?
https://rpc.jenkins.cit.rackspace.net/view/Multi-Node AIO/job/OnMetal_Multi_Node_AIO_master-xenial-periodic/
https://rpc.jenkins.cit.rackspace.net/view/Multi-Node AIO/job/OnMetal_Multi_Node_AIO_master-trusty-periodic/
How can we verify your issue is addressed?
If you are using or know of a workaround please describe the necessary steps?
What is your evaluation on the importance of this issue, and why?

This section is completed during the issue resolution process. If you are reporting an issue, please do not modify the section below.
Which branches are impacted by this issue?
Remove branches that are not impacted.
For each pull request, update the branch line to reference it.

[x] master
[ ] newton-14.0
[ ] mitaka-13.1
[ ] liberty-12.2

Upgrade impact. Consider the impact on moving between major, minor and patch releases.

[ ] This change does not impact upgrades
[ ] This change addresses a potential upgrade impact
[ ] The upgrade impact is being tracked by another issue.

The issue tracking the upgrade impact is:
Testing impact

[ ] An issue/pull-request has been create or exists to track the testing gap, and is referenced below
[ ] This change includes additional testing
[ ] This change is tested by the existing setup

Additional testing links:
Release note

[ ] This change includes a release note.
[ ] This change does not require a release note.

Doc Impact
Does your change require documentation?

[ ] Yes, and I submitted an issue to Docs issues
[ ] Yes, and I contributed a documentation patch to docs-rpc
[ ] No documentation required for this change

Additional documentation links (please add links if you have ticked yes):

cc @major @antonym

Inventory group on this one need changing? https://github.com/rcbops/rpc-openstack/pull/1896

Update: Creating multi-node-aio with master

Based on what we talked about earlier, it seems like one of two things may be happening:
MaaS is putting checks where they shouldn't be.
I'm not sure what runs on loadbalancer1 normally, but if we don't have containers on that host, the MaaS plays should not be deploying checks there for container storage. We don't deploy containers for haproxy (if that's what this node is for).
The lxc-hosts role isn't being applied.
If this host really does have containers, but the python-lxc2 module is missing, then the lxc-hosts role was skipped here. That's surprising since the code needed to make lxc-attach work for the Ansible ssh connection plugin is found within python-lxc2.

@alextricity25 @cjloader @cloudnull Hi all, this reported issue is still causing MaaS failures on a multi-node mitaka-13.1 build.  I assume it would also cause issues on liberty-12.2 when deployed on multi-node but we do not gate a multi-node on liberty at present.  The issue is that the check in https://github.com/rcbops/rpc-openstack/blob/mitaka-13.1/rpcd/playbooks/roles/rpc_maas/tasks/main.yml#L79-L81 is applied to all hosts, however not every host has LXC containers on it (or LXC, for that matter).  The actual python check being called does an import lxc, and this library isn't installed on a host when LXC has not been installed.
I mentioned this to @cloudnull last week, but want to discuss here to confirm that everyone is happy with my proposal.  Essentially, this change is in liberty-12.2/mitaka-13.1, but not newton-14.0.  In newton-14.1, we use the new rpc-maas role, where this check appears to be implemented correctly (see https://github.com/rcbops/rpc-maas/blob/master/playbooks/maas-container-storage.yml#L16-L31).  What I suggested to @cloudnull is that we revert the commits bringing this check into liberty-12.2 and mitaka-13.1 and allow it to get introduced properly when those branches start consuming the rpc-maas.  Alternatively, we can try to patch liberty-12.2/mitaka-13.1 with the implementation in rpc-maas.
The last liberty/mitaka tags were cut after this new check was added, however I suppose support could in theory be using the rpc_mass role for the liberty-12.2/mitaka-13.1 branches themselves?  Do any of you know?
Thoughts?
--Matt

What I suggested to @cloudnull is that we revert the commits bringing this check into liberty-12.2 and mitaka-13.1 and allow it to get introduced properly when those branches start consuming the rpc-maas

:+1:

@BjoernT can you please confirm that support do not deploy rpc-maas from head of liberty-12.2/mitaka-13.1?  Can I assume that because the affected checks are affecting multi-node deployments that support isn't?

This seems to be an isolated test to deploy rpc-maas standalone ? Support still uses the rpc_maas role bundled inside RPC-O so that would not be a problem for us. But we are also testing the rpc_maas standalone role which would come out of head AFIK. @npawelek may speak to that, since he's testing it

Hi @BjoernT, we've actually found a regression in gating liberty-12.2 and mitaka-13.1 on a multi-node deployment because the plugin container_storage_checks.yaml.j2 is executed on all hosts but should only be run on those w/ LXC containers.  My proposal was to remove this check from liberty-12.2/mitaka-13.1 branches and let it get fixed in the standalone role.  I just wanted to be sure I wasn't going to cause any issues removing that check in liberty/mitaka incase support is deploying checks from the head of those two branches.

Our goal is to deploy the standalone role for all releases, that's why Kevin made it Ansible 1.9 compatible. It's fine for me to fix it there. Once we tested the standalone role we can update our maintenance plans for the old releases and upgrades

Sounds good @BjoernT, I'll get these broken checks removed from liberty/mitaka then.  The checks are already good in standalone role, it's just a matter of getting rpc-o's liberty/mitaka to use that role.


SCHEDULED tasks never being provided to polling workers

Conductor version: v2.14.0
Persistence configuration: single-instance Redis

We have a task that has a concurrent_execution_limit of 1. We queued up 5000 workflows nearly simultaneously, each of which ran that task. Processing went normally for the first ~1150 workflows. Then, Conductor continued processing the remaining workflows, but would get stuck on that concurrently-limited task. All remaining (~3850) workflows have that task in the SCHEDULED state. Conductor is continuously printing for each of the tasks:
Task execution count limited. task - <TASK_ID>:<TASK_DEF_NAME>, limit: 1, current: 0"

Looking at the queue for that task, we see the number of tasks getting decremented as the tasks are added to the TASK_LIMIT_BUCKET. Eventually the sweeper puts those tasks back into the queue.
No task of this type ever leaves the SCHEDULED state once it's stuck like this. Manually clearing the TASK_LIMIT_BUCKET (DEL conductor:conductor.TASK_LIMIT_BUCKET.<TASK_DEF_NAME>) allows for some processing to happen, but it gets stuck again after ~30 workflows.
We can see that tasks are regularly being removed from the TASK_LIMIT_BUCKET (by checking with PSUBSCRIBE __keyspace@0__:conductor:conductor.TASK_LIMIT_BUCKET.<TASK_DEF_NAME>), because we can see zrem commands. From our understanding of the code flow, this should only happen in one of three cases for task instance A:

When task instance A is updated (RedisExecutionDAO::updateTask)
When task instance B is being limited and task instance A is IN_PROGRESS (RedisExecutionDAO::exceedsInProgressLimit)
When task instance A is removed (RedisExecutionDAO::removeTask)
None of these appear to be the case for us since no tasks are leaving the SCHEDULED state and we're not updating the tasks manually.

We're not certain whether we're misunderstanding the flow or this is a bug in Conductor's rate limiting functionality. Any assistance would be greatly appreciated.
P.S. if someone with appropriate understanding is reading this, could you explain the difference between the TASKS_IN_PROGRESS_STATUS and IN_PROGRESS_TASKS lists?

@indiv0 Seems like this could be something related to Redis. Since clearing the key manually fixes the issue but resurfaces after a while, I believe this is not caused by application (Conductor) code.


format for enums

Other packages like github.com/xeipuuv/gojsonschema support writing
jsonschema="enum=val1,val2"

instead of
jsonschema="enum=val1,enum=val2"

Shouldn't invopop support this more concise format, too?

Personally, I'd like to migrate away from the jsonschema= prefix entirely and take a similar approach to "swaggest/openapi-go" that uses the property names directly, e.g. enum="val1,val2" as opposed to to jsonschema="enum=val1". Alas, little time at the moment.


MPU9250 Magnetometer does not respond

Sorry if this is inappropriate, but your sketches work perfectly for me besides the magnetometer. I could not see anything on your blog for troubleshooting this. Do you perhaps know what can cause this? I am using this breakout board with my ESP32:  https://www.amazon.ca/CANADUINO-InvenSense-Accelerometer-Magnetometer-Compatible/dp/B07M76H9CM
Any help is appreciated, danke.

Hi @Andyinater, can you tell me more about the issue? Does is not compile, do you get wrong result or no results? That will help me to resolve it.

@Andyinater , I have just tried it with an ESP32 and it worked. My MPU9250 looks like yours apart from the label which is MPU9250/6500 on mine and MPU92/65 on yours.  But that shouldn't make any difference.
I tried the unchanged MPU_9250_all_data.ino and MPU9250_magnetometer_data.ino sketches. Which one did you try? And did you change anything?
Do you get the message "Magnetometer does not respond"?

Hi @wollewald, it compiles fine. When running the magnetometer example sketch "MPU9250_magnetometer_data.ino"
  if(!myMPU9250.initMagnetometer()){     Serial.println("Magnetometer does not respond");   }   else{     Serial.println("Magnetometer is connected");   }
Results in the serial print "Magnetometer does not respond". Could it be because I am using custom pins for I2C? Is there a global variable I can define I2C pins? Sorry, I am very new to all of this.

If the accelerometer and the gyroscope are working then in theory there shouldn't be an issue with your I2C settings.
If you take another sketch which also uses the accelerometer, e.g. MPU9250_all_data, do you only get the "Magnetometer does not response" message or also "MPU9250 does not respond"?

Only the 'Magnetometer does not respond' message, and then it proceeds to output reasonable data for accel and gyroscope, but magneto returns all 0s

Then this might be related with the way I implemented the magnetometer. Maybe this does not work with every module. I have ordered a module which look exactly like yours. But this will take some time until they arrive.
Maybe I will rewrite the library and implement an alternative way of implementing the magnetometer. But I can't promise a timeline.

@Andyinater , I have fundamentally changed the way to retrieve magnetometer data. I have released a new version. I hope you are still motivated to try. That would help me a lot since I can't reproduce the issue with my module.
Occasionally, but only after upload of sketches, you might need to disconnect from power and repower again.

@wollewald Wow, I did not expect such a response and I greatly appreciate it.
Unfortunately, I am still getting the same response. MPU9250 is connected, Magnetometer does not respond.

OK - that's of course disappointing. Maybe I can reproduce and then solve the issue when I get the MPU9250 modules that I have ordered and which look more like yours. But they come from the US and that will take few weeks.
Have you tried another library and did it work? This one worked for me:
https://github.com/bolderflight/mpu9250-arduino

For that one, I am uncertain on how to manually declare my I2C SCL and SDA pins. I attempted modifying his "mpu9250.cpp" under the method Mpu9250::Begin() by changing
i2c_->begin();
to
i2c_->begin(33,32);
Although this results in "IMU initialization unsuccessful"

Honestly, at this point I'm wondering if I somehow got a knock-off unit without the magnetometer in it. If every library gives me a problem, I am the problem... lol

To be honest I was also not sure how to do that. There is no way to pass the SDA / SCL pins. I just took the Basic I2C example and it worked with the pins 18/19 like this:
#include "MPU9250.h"
TwoWire myWire = TwoWire(0);

// an MPU9250 object with the MPU-9250 sensor on I2C bus 0 with address 0x68
MPU9250 IMU(myWire,0x68);
int status;

void setup() {
  // serial to display data
  Serial.begin(115200);
  while(!Serial) {}
  myWire.begin(18,19);
  // start communication with IMU
  status = IMU.begin();
.......

Good luck!

So, I used the library by Kris Weiner and some new info came out by probing what is called the "Who am I" register.
https://github.com/kriswiner/MPU9250/issues/458
It appears that I DO NOT have a genuine 9250, or I at least have a mislabeled (probably on purpose) 9255 or something. When I followed his advice in that issue, his library did end up producing magnetometer values, but I do not think I will be able to make use of them anyways.  (for my absolute orientation desires I am now looking towards the BNO055 from Bosche)
For now, I will be continuing with your library as I find it very intuitive to use. I do have a new question though: Is there a way to retrieve the offset values generated by autoOffsets()? Mainly so I can store them in flash memory so if my device accidentally power cycles I can return to logging on the previously established offsets.

Using the magentometer values is a bit tricky. Every cable on a breadboard influcences the measured values. In theory you could calibrate it. Just turn around in all directs and record the min/max values. Quite some effort. And you always have to calibrate whenever you change the location. I was a bit disappointed after the first experience.
Ihave not (yet) written a function like "getAutoOffsets". But you can determine them easily yourself. It's nothing sohisticated:
    accOffsetVal.x = 0.0;
    accOffsetVal.y = 0.0;
    accOffsetVal.z = 0.0;

    enableGyrDLPF();
    setGyrDLPF(MPU9250_DLPF_6);  // lowest noise
    setGyrRange(MPU9250_GYRO_RANGE_250); // highest resolution
    setAccRange(MPU9250_ACC_RANGE_2G);
    enableAccDLPF(true);
    setAccDLPF(MPU9250_DLPF_6);
    delay(100);

    for(int i=0; i<50; i++){
        getAccRawValues();
        accOffsetVal.x += accRawVal.x;
        accOffsetVal.y += accRawVal.y;
        accOffsetVal.z += accRawVal.z;
        delay(1);
    }

    accOffsetVal.x /= 50;
    accOffsetVal.y /= 50;
    accOffsetVal.z /= 50;
    accOffsetVal.z -= 16384.0;

    for(int i=0; i<50; i++){
        getGyrRawValues();
        gyrOffsetVal.x += gyrRawVal.x;
        gyrOffsetVal.y += gyrRawVal.y;
        gyrOffsetVal.z += gyrRawVal.z;
        delay(1);
    }

    gyrOffsetVal.x /= 50;
    gyrOffsetVal.y /= 50;
    gyrOffsetVal.z /= 50;

For long term storage I would recommend the other procedure I have implemented with the min / max values for the axes. It's bit more effort but a one off.

Thank you so much for your help, I think I will finally be able to complete my prototype.

HI Wolle,
thanks for putting all that into nice library.
I have similar problem with different pre-defined SDA/SCL that I want to pass during the setup() phase.
Is it possible to add function .setWire similar like:  https://github.com/asukiaaa/MPU9250_asukiaaa/blob/master/src/MPU9250_asukiaaa.h
lines 39-41
That way I could easily do something like this in dhe setup:
#define SDA_PIN 21
#define SCL_PIN 22
Wire.begin(SDA_PIN, SCL_PIN);
myMPU9250.setWire(&Wire);
Otherwise I can do complete init inside setup:
void setup() {
Serial.begin(115200);
#ifdef ESP32_HAL_I2C_H // For ESP32
Wire.begin(SDA_PIN, SCL_PIN); // SDA, SCL
#else
Wire.begin();
#endif
MPU9250_WE myMPU9250 = MPU9250_WE(&Wire);
if(!myMPU9250.init()){
Serial.println("MPU9250 does not respond");
}
else{
Serial.println("MPU9250 is connected");
}
But then inside loop() it is not defined  myMPU9250 and can't compile.
Thanks!

@ivicajan , you can predefine the SDA and SCL pins and pass it to your MPU9250 object. I have tried this on an ESP32.
Like this, e.g.:
#define I2C_FREQ 400000
#define SDA_PIN 21
#define SCL_PIN 22
#define MPU9250_ADDR
TwoWire wire1 = TwoWire(1);

MPU9250_WE myMPU9250 = MPU9250_WE(&wire1, MPU9250_ADDR);

void setup() {
  wire1.begin(SDA_PIN, SCL_PIN, I2C_FREQ);
.......

Thanks!
it's working.
Cheers,
Ivica
On Sun, 26 Sept 2021 at 16:57, Wolfgang (Wolle) Ewald <
@.***> wrote:

@ivicajan https://github.com/ivicajan , you can predefine the SDA and
SCL pins and pass it to your MPU9250 object. I have tried this on an ESP32.
Like this, e.g.:
#define I2C_FREQ 400000
#define SDA_PIN 21
#define SCL_PIN 22
#define MPU9250_ADDR
TwoWire wire1 = TwoWire(1);
MPU9250_WE myMPU9250 = MPU9250_WE(&wire1, MPU9250_ADDR);
void setup() {
wire1.begin(SDA_PIN, SCL_PIN, I2C_FREQ);
.......
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/wollewald/MPU9250_WE/issues/1#issuecomment-927263418,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEN4TMAKPQTIKUQSPLZLPILUD3N67ANCNFSM45JQZZEQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

@sparkplug23, have you tried other libraries and do you get magnetometer results with these?

@sparkplug23, have you tried other libraries and do you get magnetometer results with these?

I have tried others, but the values I am getting out are completely random. It doesn't even appear to be noise, it can go from +2000 to -2000 etc on each new sample.
I dug into your library, and the function that reads the register is getting 0 for the value. _wire->available () is correctly showing as one byte, but that result (_wire->read()) is always 0.
For now, after wasting the last 2 days I've switched to another IMU I have (gy89) and am getting sensible values with it. I'll need to spend more time trying to debug the issue with the mpu9250. I briefly looked at its datasheet (though I suspect it was an abrievated version) and didn't really see the register/i2c handshake I needed to do to get the values out of the magnetometer.

Since I have not heard anything I close this issue now.

Just wanted to put my 5 cents. Today I received from Ali some modules advertised as MPU9250. The magnetometer data is just 0. Acc/Gyr data seems okay. So I believe Ali sellers just got batches of MPU9250 with broken magnetometer and resells them.

Hi @vladkozlov69 , thanks for this info. Can you run the example sketch who_am_i.ino ? Maybe you have one of the modules which have the MPU6500 (or other) instead of the MPU9250.

Hi @wollewald here it is
WhoAmI Register: 0x75 Your device is probably an MPU6515 Not sure if it works with this library, just try


Will this work for Hue Entertainment

Hi,
I want to know if this library can be used in my project for emulating the Hue Entertainment future. My project is build in Python 3 and the requirements for Hue Entertainment are these:

DTLS Handshaking
UDP port 2100 is used for DTLS handshaking and streaming. Only DTLS mode version 1.2 with Pre-Shared Key (PSK) Key exchange method with TLS_PSK_WITH_AES_128_GCM_SHA256 set as Cipher Suite is supported.

Thanks.

seems like there is some problem when running the server side with cipher=PSK. It seems to work fine on the client side, as it requests the PSK cipher suite successfully. I started a conversation regarding this in a separate post. For Hue entertainment are you the client or server?

Actually when setting cipher="PSK" I only see these 3 being requested in wireshark it doesn't have the one you need with GCM_SHA256
Cipher Suite: TLS_PSK_WITH_AES_256_CBC_SHA (0x008d)
Cipher Suite: TLS_PSK_WITH_AES_128_CBC_SHA (0x008c)
Cipher Suite: TLS_PSK_WITH_3DES_EDE_CBC_SHA (0x008b)

Hi,

For Hue entertainment are you the client or server?
i'm the server. Can you share the server code you tried?

Thanks.


[Game Crash] Crashing on startup

Raspberry Pi 4
Twister OS 2.1.2
OutFox 5.3 Alpha 4.9.8
I navigate to the OutFox folder, and run ./stepmania
Games crashes immediately on startup.
consoleoutput.txt
crashinfo.txt

Update: I've tried every version of OutFox, from 4.9.0 onwards.
Starting from 4.9.5 and up, I get the above error.
Below 4.9.5 down to 4.9.0 I get a different error, in a loop:
WARNING: ALSA: snd_pcm_wait: Broken pipe

The game might be trying to use ALSA but it is unavailable at the moment, resulting in the crash. Try changing the SoundDrivers parameter in Preferences.ini to Pulse

@SheepyChris there's no Preferences.ini file in the /.stepmania-5.3/Save folder, only OutFoxPrefs.ini
I tried adding SoundDrivers=Pulse there, but no change.
Any suggestions what to try with 4.9.5 and up? It's giving these errors:
Lights driver: Export
/////////////////////////////////////////
WARNING: Unmatched 3 in "0003"
/////////////////////////////////////////
/////////////////////////////////////////
...
WARNING: Unmatched 3 in "0003"
/////////////////////////////////////////
Video renderers: 'opengl,glad'
ptrace failed: Operation not permitted
...
ptrace failed: Operation not permitted
StepMania 5.3 has crashed.

I see this might be related to
https://github.com/TeamRizu/OutFox/issues/216
I see a fix is being released for 4.9.9, is twister one of the fixes?

This is because Twister requires the 32bit build (ARMv7) I'll dig out my pi400 later today and see what's making it crash, and will update.

hellos!
I have run the latest 4.9.9HF3b on a freshly written Twister OS 2.1.2 - the game seems to run fine here

Just extracted it to my desktop to test.
Can you let me know where your installation is?