Check for existence of a class before performing some operations

Fixes #105, #106, #109.
Changes:

In JsonSerializableTaAssist, after loading the students and classes, check if each class of each students exists in the loaded classes.
In AddCommand and EditCommand, check if all classes of the student being added/edited is present in the model.

Codecov Report
Base: 60.41% // Head: 61.08% // Increases project coverage by +0.66% :tada:

Coverage data is based on head (e38b7d1) compared to base (6218538).
Patch coverage: 37.93% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master     #112      +/-   ##
============================================
+ Coverage     60.41%   61.08%   +0.66%
- Complexity      413      423      +10
============================================
  Files            87       87
  Lines          1498     1516      +18
  Branches        160      166       +6
============================================
+ Hits            905      926      +21
+ Misses          548      542       -6
- Partials         45       48       +3

Impacted Files
Coverage Δ

...ain/java/seedu/taassist/commons/core/Messages.java
0.00% <ø> (ø)

...java/seedu/taassist/logic/commands/AddCommand.java
85.71% <0.00%> (-14.29%)
:arrow_down:

...a/seedu/taassist/logic/commands/AssignCommand.java
0.00% <0.00%> (ø)

...va/seedu/taassist/logic/commands/ClassCommand.java
0.00% <0.00%> (ø)

.../seedu/taassist/logic/commands/DeletecCommand.java
0.00% <0.00%> (ø)

...ava/seedu/taassist/logic/commands/EditCommand.java
94.28% <0.00%> (-2.78%)
:arrow_down:

...seedu/taassist/logic/commands/UnassignCommand.java
0.00% <0.00%> (ø)

src/main/java/seedu/taassist/model/Model.java
100.00% <ø> (ø)

...java/seedu/taassist/model/util/SampleDataUtil.java
14.28% <0.00%> (-5.72%)
:arrow_down:

...edu/taassist/storage/JsonSerializableTaAssist.java
86.20% <80.00%> (+10.20%)
:arrow_up:

... and 9 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Bump prometheus

This PR:

bumps prometheus to latest

Checklist

[x] Update changelog in CHANGELOG.md.
[x] Test on Workload cluster.

Not really, string interning won't hit before 2.52 by default. I just wanted to use the latest version. I'm not sure about rénovate though


A lot of intermittent UH errors on istio egress gateway

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
INFO 2024-03-25T08:56:41.897522475Z [resource.labels.containerName: istio-proxy] [2024-03-25T08:56:41.328Z] "- - -" 0 UH - - "-" 0 0 0 - "-" "-" "-" "-" "-" outbound|443||xxx.segment.xxx - xxxxx:8443 xxxxx:38532 xxxx.segment.xxx -
A lot of UH errors on istio egress gateway. We are seeing these errors as intermittent. Need your help to resolve this issue permanently.
We already set HPA for istio egress gateway.
Version
istioctl version
client version: 1.18.7
control plane version: 1.18.7
data plane version: 1.18.7 (1212 proxies)

kubectl version --short
Client Version: v1.26.10
Server Version: v1.26.10

Additional Information
No response

Hi, UH means unhealthy upstream. For egress gateway, this means the external service beyond egress gateway is unhealthy. You can use istioctl pc endpoint  istio-egressgateway-$POD_ID.istio-system |grep segment (segement is your svc partial name) to query the svc's healthy.
Moreover, your may be need to check destination rule(alias to DR) for the external service, because the healthy status provided by istioctl is queried according to the DR.

Hi, UH means unhealthy upstream. For egress gateway, this means the external service beyond egress gateway is unhealthy. You can use istioctl pc endpoint istio-egressgateway-$POD_ID.istio-system |grep segment (segement is your svc partial name) to query the svc's healthy.
Moreover, your may be need to check destination rule(alias to DR) for the external service, because the healthy status provided by istioctl is queried according to the DR.
Check endpoint health detail:
istioctl pc endpoint  istio-egressgateway-$POD_ID.istio-system --cluster "outbound|443..." -ojson

Sure, thanks for the suggestion. We will check on this but we are facing this UH behaviour intermittenly for some URLs. I am not sure if istioctl really help here?

There is a possiblity is that envoy default to reuse connection for HTTP/1.1, but the connection has been closed when it was reused. This case happened intermittenly is due to it only happened on a time window exists.
So now you can set maxRequestsPerConnection=1 in DR manifest, this field's default value is zero means unlimited.

One possibility is that the envoy defaults to reusing HTTP/1.1 connections upstream, but the connection has been closed when it was reused. This case happenes intermittenly is due to it only happenes on a time window exists.
So now you can set connectionPool.http.maxRequestsPerConnection=1 in trafficPolicy of DR manifest, this field's default value is zero means unlimited. This setting may cause perf issues, and another solution is to set retries.attempts=3 in the VR manifest, you can have a try on it~

Thank you so much for your response. We will check and update on it.

One possibility is that the envoy defaults to reusing HTTP/1.1 connections upstream, but the connection has been closed when it was reused. This case happenes intermittenly is due to it only happenes on a time window exists.
So now you can set connectionPool.http.maxRequestsPerConnection=1 in trafficPolicy of DR manifest, this field's default value is zero means unlimited. This setting may cause perf issues, and another solution is to set retries.attempts=3 in the VR manifest, you can have a try on it~

We are not able to resolve this UH errors.
We are planning to route the traffic through NSG/ firewall along with istio service entry. During the process, when adding individual domains, it is working fine. But with the wildcard domains, this is not working. Any suggestions on it?
Below error when we use wildcard on istio service entry with*.facebook.com
/ # curl
https://www.facebook.com/
-Iv

Trying <IP_ADDRESS>:443...
Connected to
www.facebook.com
(<IP_ADDRESS>) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
successfully set certificate verify locations:
CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
TLSv1.3 (OUT), TLS handshake, Client hello (1):
OpenSSL SSL_connect: Connection reset by peer in connection to
www.facebook.com:443
Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to
www.facebook.com:443

You might paste curl client pod's istio-proxy log here.

You might paste container istio-proxy log of curl client pod here. See also https://istio.io/latest/docs/tasks/observability/logs/access-log/#using-mesh-config to open access log.

@howardjohn , Can you help me on this issue? @chaseSpace

@howardjohn , Can you help me on this issue? @chaseSpace

Hi Team,
Can anyone help here?

@howardjohn , Can you help me on this issue? @chaseSpace

Hi Team, Can anyone help here? We are having more than huge clusters using wildcard model, hence need your suggestion at earliest.

Hi Team, any suggestions on this issue

I am come back!

Hey guy, I think i found some points.
Firstly, if the host is a real external address(along withMESH_EXTERNAL), we should set resolution to DNS inside SE manifest, or the gateway will direct the traffic to itself in an infinite loop. This can be found with below context:
DNS resolution must be used in the service entry below. If the resolution is NONE, the gateway will direct the traffic to itself in an
 infinite loop. This is because the gateway receives a request with the original destination IP address which is equal to the service
IP of the gateway (since the request is directed by sidecar proxies to the gateway).

From blog Egress Gateways.
Secondly, if we specified a real external wildcard prefix domain as host, we can only specify resolution as STATIC, and   resolution must not be NONE, it would cause infinite route loop. NONE only can be used with requested target already is a IP not a domain.
So here we need to add some endpoints, like below:
...
  location: MESH_EXTERNAL
  endpoints:
    - address: <IP_ADDRESS> # replace with real fb ip

Then we can access hosts matched with wildcard host on mesh container:
~ $ curl https://www.facebook.com -w '%{http_code}\n' -s -o /dev/null -L
200

And we can check out egress pod log:
[root@k8s-master ~]# kubectl logs -l app=istio-egressgateway -n istio-system --tail=1
{"x_forwarded_for":null,"start_time":"2024-05-23T03:15:15.117Z","connection_termination_details":null,"upstream_transport_failure_reason":null,"response_flags":"-",
"downstream_remote_address":"<IP_ADDRESS>:33030","duration":756,"user_agent":null,"response_code_details":null,"upstream_local_address":"<IP_ADDRESS>:48018",
"upstream_host":"<IP_ADDRESS>:443","path":null,"requested_server_name":"www.facebook.com","request_id":null,"upstream_service_time":null,
"method":null,"authority":null,"downstream_local_address":"<IP_ADDRESS>:8443","response_code":0,"upstream_cluster":"outbound|443||*.facebook.com",
"bytes_received":860,"bytes_sent":73988,"protocol":null,"route_name":null}

Well, i think also this config method is not a good practice, so it may not be recommend for wildcard prefix host usage. I would expect istio expert to clarify it.

Hey guy, I think i found some points.
Firstly, if the host is a real external address(along withMESH_EXTERNAL), we should set resolution to DNS inside SE manifest, or the gateway will direct the traffic to itself in an infinite loop. This can be found with below context:
DNS resolution must be used in the service entry below. If the resolution is NONE, the gateway will direct the traffic to itself in an
 infinite loop. This is because the gateway receives a request with the original destination IP address which is equal to the service
IP of the gateway (since the request is directed by sidecar proxies to the gateway).

From blog Egress Gateways.
Secondly, if we specified a real external wildcard prefix domain as host, we can only specify resolution as STATIC, and resolution must not be NONE, it would cause infinite route loop. NONE only can be used with requested target already is a IP not a domain.
So here we need to add some endpoints, like below:
...
  resolution: STATIC
  location: MESH_EXTERNAL
  endpoints:
    - address: <IP_ADDRESS> # replace with real fb ip

Then we can access host matched with wildcard host on mesh internal container:
~ $ curl https://www.facebook.com -w '%{http_code}\n' -s -o /dev/null -L
200

And we can check out egress pod log:
[root@k8s-master ~]# kubectl logs -l app=istio-egressgateway -n istio-system --tail=1
{"x_forwarded_for":null,"start_time":"2024-05-23T03:15:15.117Z","connection_termination_details":null,"upstream_transport_failure_reason":null,"response_flags":"-",
"downstream_remote_address":"<IP_ADDRESS>:33030","duration":756,"user_agent":null,"response_code_details":null,"upstream_local_address":"<IP_ADDRESS>:48018",
"upstream_host":"<IP_ADDRESS>:443","path":null,"requested_server_name":"www.facebook.com","request_id":null,"upstream_service_time":null,
"method":null,"authority":null,"downstream_local_address":"<IP_ADDRESS>:8443","response_code":0,"upstream_cluster":"outbound|443||*.facebook.com",
"bytes_received":860,"bytes_sent":73988,"protocol":null,"route_name":null}

Well, i think also this config method is not a good practice, so it may not be recommend for wildcard prefix host usage. I would expect istio expert to clarify it.

Thank you @chaseSpace , we will for istio team suggestion on this issue


Krakend bloomfilter server log

Team,
We wrote go client for bloomfilter. However, when it connects to bloomserver on krakend container through rpc, it does not capture by itself any log if there is any communication established. even with log level "Debug" set on krakend.json. Please suggest how to enable the logs on bloomfilter server hosted on krakend container (port 1234).

The bloomfilter server does not write any logs.
If you want to enable logs in the server, you will need to fork the component


Infinite loader when editing an email

Repro steps:

Edit email
receive verify new email to updated email , ignore it
Go back to W3M
Edit email again
Infinite spinner

Expected result:

Resends verification email.
https://www.loom.com/share/4b6d7b4a3d444140ab2515138b02bb88

Should be unblocked / solved once https://github.com/WalletConnect/web3modal/issues/1851 is completed


Feat jobqueue

Implements a fairly simply job queue, but there is no definition of what a job is yet. It'll probably be a std::function so we can throw lambda functions into it. But maybe we can throw data into it instead.. and if we need to process different things we could use a tuple and/or union to send it both types.. this is something we should discuss.

@brianzhouzc has agreed to write the unit test, so that's coming next.

It seems to be crashing Orthanc for some reason.
I added  JobQueue::GetInstance().AddJob([&](){DEBUG_LOG(1,"Debug Log from Job queue");}); to WriteDicomFile() and this is the result:
orthanc-server  | W0208 20:38:31.063911 PluginsManager.cpp:168] Debug Log from Job queue
orthanc-server  | W0208 20:38:31.064014 PluginsManager.cpp:168] WriteDicomFile: permissions set
postgres        | 2022-02-09 04:38:31.069 UTC [43] LOG:  could not receive data from client: Connection reset by peer
postgres        | 2022-02-09 04:38:31.069 UTC [43] LOG:  unexpected EOF on client connection with an open transaction
orthanc-server exited with code 139

It seems to be crashing Orthanc for some reason.
I added  JobQueue::GetInstance().AddJob([&](){DEBUG_LOG(1,"Debug Log from Job queue");}); to WriteDicomFile() and this is the result:

Logging utilities are often not thread safe in these situations and will trigger a segfault. This morning I wrote the unit test to make sure the JobQueue works. Then I wrote the following test code in the plugin initialization to test that it can work in the plugin. Note the only reason the logging doesn't crash, probably, is that this code is effectively serial because of the large loops.
        job_thread = std::thread(&JobQueue::Process, &JobQueue::GetInstance());
        for(int i = 0 ; i < 1000000; ++i){}
        std::atomic<bool> job_done = false;
        std::string b = "the result of adding the job was: " + std::to_string(JobQueue::GetInstance().AddJob([&](){
            job_done = true;
            DEBUG_LOG(-1, "job completing");
            DBInterface::create_tables();
        }));
        DEBUG_LOG(-1,b.c_str());
        for(int i = 0 ; i < 1000000; ++i){}
        std::string d = "the job state is: " + std::to_string(job_done.load());
        DEBUG_LOG(-1, d.c_str());

The corresponding output:
orthanc-server  | W0209 10:40:12.387721 main.cpp:878] Loading plugin(s) from: /usr/share/orthanc/plugins
orthanc-server  | W0209 10:40:12.391129 PluginsManager.cpp:269] Registering plugin 'data-anonymizer' (version 0.5)
orthanc-server  | E0209 10:40:12.398037 PluginsManager.cpp:164] the result of adding the job was: 1
orthanc-server  | E0209 10:40:12.398053 PluginsManager.cpp:164] job completing
orthanc-server  | E0209 10:40:12.399793 PluginsManager.cpp:164] the job state is: 1
orthanc-server  | W0209 10:40:12.399817 main.cpp:878] Loading plugin(s) from: /usr/local/share/orthanc/plugins

Except it doesn't work in CI


Convert domains compendiums into paged format

Intermediate step before killing off

Is it not linked in several places?

All gone


Migrate the registry repository here and add the schemas' relative paths to the registry

The reasoning behind it is at https://github.com/okfn/datapackage-registry-py/issues/2

Yes, as discussed. Please PR.


Ensure WithArgs can be used with executable resources

This is follow up to https://github.com/dotnet/aspire/pull/1308 which incorrectly constrained WithArgs to ContainerResource resources only.
This needs to be backported to preview.2 also.
Microsoft Reviewers: Open in CodeFlow

/backport to release/8.0-preview2

Closing this out after talking to @davidfowl. We don't need to expose this publicly for executables for now.


Excellence Programma 1

I added a new project - Mashal and Kathleen Nuant at Taranta vzw

First update after 6 months  - one new project added.


module 'qiskit' has no attribute '_accelerate' when running with accelerated numpy

Environment

Qiskit version: 1.0.1
Python version: 3.10
system: Google colab

What is happening?
I am using cupy and accelerarted numpy to improve performance of some code. When using cupy and numpy alsong with qiskit libraries the installation gives qiskit._accelerate not found error.
----------------------------------
AttributeError                            Traceback (most recent call last)
[<ipython-input-9-50bfb866a323>](https://localhost:8080/#) in <cell line: 6>()
      4
      5 from lattice import ZigzagSquareLattice, SquareLattice
----> 6 from hamiltonian import SkyrmionHamiltonian
      7 # from ansatz import SkyrmionAnsatz

1 frames
[/content/quantum-skyrmion-simulation/./src/hamiltonian.py](https://localhost:8080/#) in <module>
      4 import subprocess
      5 from lattice import Lattice
----> 6 from qiskit.quantum_info import SparsePauliOp
      7 from qiskit_algorithms import NumPyMinimumEigensolver
      8

[/usr/local/lib/python3.10/dist-packages/qiskit/__init__.py](https://localhost:8080/#) in <module>
     53 # We manually define them on import so people can directly import qiskit._accelerate.* submodules
     54 # and not have to rely on attribute access.  No action needed for top-level extension packages.
---> 55 sys.modules["qiskit._accelerate.nlayout"] = qiskit._accelerate.nlayout
     56 sys.modules["qiskit._accelerate.stochastic_swap"] = qiskit._accelerate.stochastic_swap
     57 sys.modules["qiskit._accelerate.sabre_swap"] = qiskit._accelerate.sabre_swap

AttributeError: partially initialized module 'qiskit' has no attribute '_accelerate' (most likely due to a circular import)

This issue fixes itself sometimes when I restart the kernel and it is fixed. I also tried to use 0.46 qiskit version but same issue. The code works fine if I dont use accelerated numpy/cupy.
How can we reproduce the issue?
Installations
sudo apt-get install numpy libopenblas-dev
pip install cupy-cuda12x
pip install qiskit==0.46.1
pip install qiskit_algorithms==0.3.0

Use qiskit imports
What should happen?
The imports should happen without error.
Any suggestions?
No response

Please can you give more detail about what precisely you've run in a clean Colab session, both to install additional packages (both pip and the system package manager) and then try to produce a minimal reproducer of a failure that doesn't involve any of the additional packages you've got?
Fwiw, if the cupy installation is changing anything about what happens when you import numpy or any of the internal objects, then it's quite likely that Qiskit simply isn't compatible with that - we use Numpy's C API, so if anything is messing with Numpy internals, we could very quickly be getting out of sync.

I was unable to reproduce it following the How can we reproduce the issue? instructions.

Hi @tinaoberoi, I'm closing this as stalling and unreproducible. Please, reopen if that's not the case.


Get the PDO class/connection

Although Slim-PDO has almost every wanted feature, it doesn't cover all the MySQL (or other DB's) features. Is it possible to call the main \PDO class when needed?
Thanks. :)

Hi @francoism90, the Database class extends directly from \PDO, so you can use all the familiar methods and features whenever you feel like it. Slim-PDO doesn't overwrite any of those methods. 😉

Oh that's great!  :)
Thanks for the reply.


Drop Python3.7, require 3.8+

This reverts commit f21e6768a7e970e3ec0f3c4b818f47f8dfd1c92b ... which, in turn, reverted https://github.com/fonttools/fonttools/pull/2879

Fixes https://github.com/fonttools/fonttools/issues/2878 and https://github.com/fonttools/fonttools/issues/2163

I'll take @typemytype's

Dropping 3.7 is all fine for me!

as an implicit LGTM, so I'll go on and merge this


[LIVY-400][BUILD]Add script to handle Livy apache release process

This PR adds script to handle Livy apache release process.

Codecov Report

Merging #42 into master will increase coverage by 0.18%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master      #42      +/-   ##
============================================
+ Coverage     70.73%   70.91%   +0.18%
- Complexity      787      788       +1
============================================
  Files            97       97
  Lines          5388     5388
  Branches        802      802
============================================
+ Hits           3811     3821      +10
+ Misses         1033     1022      -11
- Partials        544      545       +1

Impacted Files
Coverage Δ
Complexity Δ

...main/java/org/apache/livy/rsc/ContextLauncher.java
83.66% <0%> (+1.98%)
17% <0%> (-1%)
:arrow_down:

...java/org/apache/livy/rsc/rpc/KryoMessageCodec.java
98.21% <0%> (+3.57%)
19% <0%> (+1%)
:arrow_up:

...in/java/org/apache/livy/rsc/rpc/RpcDispatcher.java
68% <0%> (+4%)
20% <0%> (+1%)
:arrow_up:

Continue to review full report at Codecov.

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

Merging to master branch 0.4.


!! Big JSON file causing heap out of memory for bundler !!

Environment
Environment:
OS: Windows 10
Node: 10.8.0
Yarn: 1.3.2
npm: 6.2.0
Watchman: Not Found
Xcode: N/A
Android Studio: Not Found
Packages: (wanted => installed)
react: 16.3.1 => 16.3.1
react-native: ~0.55.2 => 0.55.4
Description
Hey everyone!
Firstly, thanks for spending the time to open this and read this. So!
I need to point out that i've just started react native 4 weeks ago from react web development.
Basically i'm making an app where i need to import a pretty big JSON file called 'cityData.json' with the size of around 23.8MB.
and one element of the JSON array looks like this...
{ "id": 707860, "name": "Hurzuf", "country": "UA", "coord": { "lon": 34.283333, "lat": 44.549999 } },
and there are plenty of these elements.
And whenever i run the code using react-native run-android, i get a memory issue from the bundler.
Heres a screenshot of what it looks like...

I spent around 3 hours searching why this was happening, and alot of people suggested something about how something shouldn't be transpiled? Something about transforming? Sorry like i said i'm a newbie. They then recommended that i "ignore": the bundle from interacting with my JSON file using .babelrc or package.json? I'm not exactly sure about what they mean about that. I don't get the **/*.js syntax. But i do know for a fact, that whenever i pass in smaller JSON files, it loads perfectly. It's just this JSON file that's wayyy to big! That progress bar just won't move...
As you can see after reading that paragraph, i'm really bad with anything to do with babel and bundles. So hopefully, you guys (who are much more experienced than me) can help me with this!
Reproducible Demo
To reproduce this,
download a JSON file with the size of 23MB
create create-react-native-app
do npm run eject
make a folder named dataFolder
move JSON file called (cityData.json) into dataFolder
in App.js add the following code:
const cityData = require('./dataFolder/cityData.json');
Then run the app with react-native run-android
Then the error will occur.

IMHO, it's not efficient to store such a large data in JSON file, and include it in an app, because it'll consume a lot of RAM. I would recommend to store it on a server and access it via API, or use proper DB.


Out of date/incorrect advice in SSL_get_error docs as of 1.1.0c

This commit changed SSL_read to return -1 rather than 0 when BIO_read returns 0: https://github.com/openssl/openssl/commit/4880672a9b41a09a0984b55e219f02a2de7ab75e, which landed in the 1.1.0c release.
When SSL_get_error is called, it'll return SSL_ERROR_SYSCALL, and the error stack will be empty. The man page for SSL_get_error says that at that point you should check SSL_read's return code; a -1 means that there was a read error and to consult the BIO-specific error (e.g. errno), and 0 means that there was an EOF in violation of the protocol, but that doesn't appear to be correct anymore.
Is this a bug in the implementation or the docs? If the new implementation is correct, I guess the new procedure should be to check the BIO error, and check if an error actually occurred to determine if it's an EOF?

In my opinion the new behavior is wrong. This new behavior results in SSL_read returning -1 with a syscall error if the peer just closes the connection without proper shutdown. But for this case SSL_read is explicitly documented as returning 0, i.e. the commit breaks a documented API.

I'm wondering if we can find the places that return -1 (from the
BIO?) that should return 0 in SSL_read.
But this all seems like non-trivial to get right.
Kurt

There are no guarantees that a 0 return from BIO_read() means EOF, e.g. by default reading from an empty mem bio gives you a return of -1 from BIO_read(), but calling BIO_eof() will return true. Some BIOs may work that way, but others may not.
Further, SSL_read() is not documented to return 0 on EOF:
=item Z<>0

The read operation was not successful. The reason may either be a clean
shutdown due to a "close notify" alert sent by the peer (in which case
the SSL_RECEIVED_SHUTDOWN flag in the ssl shutdown state is set
(see L<SSL_shutdown(3)>,
L<SSL_set_shutdown(3)>). It is also possible, that
the peer simply shut down the underlying transport and the shutdown is
incomplete. Call SSL_get_error() with the return value B<ret> to find out,
whether an error occurred or the connection was shut down cleanly
(SSL_ERROR_ZERO_RETURN).

=item E<lt>0

The read operation was not successful, because either an error occurred
or action must be taken by the calling process. Call SSL_get_error() with the
return value B<ret> to find out the reason.

The documentation for SSL_get_error() does says this:
=item SSL_ERROR_SYSCALL

Some I/O error occurred.  The OpenSSL error queue may contain more
information on the error.  If the error queue is empty
(i.e. ERR_get_error() returns 0), B<ret> can be used to find out more
about the error: If B<ret == 0>, an EOF was observed that violates
the protocol.  If B<ret == -1>, the underlying B<BIO> reported an
I/O error (for socket I/O on Unix systems, consult B<errno> for details).

However, that is quite clearly wrong. Since libssl does not know the reason behind the return code from BIO_read() it cannot be said that a ret value of 0 from SSL_read() means EOF (and it is inconsistent with the documentation for SSL_read() in any case). This should probably be fixed in the documentation.

So can you please clarify, how to detect the EOF? I would expect the API to allow for that and not to require going down to the underlying transport to find out.

My reading of the documentation you cite is the following: Return value is 0 either on a clean shutdown or if the peer simply closed the connection, i.e incomplete shutdown. Return value is -1 either if some (unspecified error) occurs or if an action needs to be taken by the caller.
Based on this reading an EOF from the client instead of a clean shutdown perfectly fits the first case, i.e. return value of 0.  And this is exactly what OpenSSL  did for years.  While it might be that of how OpenSSL internally works it never was true that 0 returned only in the documented cases it at least behaved this way in the documented cases. And applications relied on this documented behavior since it always worked as documented.
If the API stays at it is now it will cause unexpected errors in existing applications and once the source of the error is figured out the applications will need to changed in that they need to do some new error handling to figure out if the problem happened due to EOF or something else. And of course they need to maintain backwards compatibility in case they are compiled against an older version of OpenSSL.
In my opinion the API should not be simply changed like it is done currently, i.e. suddenly, silently and without even updating the API documentation.  My expectation would be instead that OpenSSL does exactly the same what it now expects from all applications, i.e. figure out if this was EOF or not. This way the necessary change would be only needed in one place (OpenSSL) and the documented API would be kept stable.

So can you please clarify, how to detect the EOF? I would expect the API to allow for that and not to require going down to the underlying transport to find out.

There is no way without asking the underlying BIO (and there never has been no matter what the documentation may have implied), i.e. call BIO_eof().

Based on this reading an EOF from the client instead of a clean shutdown perfectly fits the first case, i.e. return value of 0. And this is exactly what OpenSSL did for years. While it might be that of how OpenSSL internally works it never was true that 0 returned only in the documented cases it at least behaved this way in the documented cases. And applications relied on this documented behavior since it always worked as documented.

The simple fact is that the documentation is inconsistent with itself. The SSL_read() documentation says nothing about EOF and makes no guarantees about it. SSL_get_error() implies something different, but that doesn't match the implementation. It might have been the case that in certain circumstances the behaviour happened to behave in a certain way, and that applications then started to rely on that behaviour. But it is equally true that in other situations it did not behave that way, and did not behave like the documented API. Either way something is broken. There is no simple way out of that...we're doomed whatever we do because someone won't be happy with it.
This change at least brings some consistency to the situation (although the SSL_get_error() page should be brought in line too). There is an argument to say we shouldn't have this "fix" backported to 1.1.0 and keep it in 1.1.1....although the two are supposed to be binary compatible with each other, so that in itself is difficult.

My expectation would be instead that OpenSSL does exactly the same what it now expects from all applications, i.e. figure out if this was EOF or not.

Hmmm, that could be possible, i.e. we could call BIO_eof() and return 0 if it is true...but I suspect even there...as I said in my mem BIO example, some things don't always behave quite as you expect. So I think we would still end up breaking applications.
The choice really comes down to keep it like it was (broken in some situations, but kind of did something sort of predictable in some situations, but that behaviour doesn't match the documentation (and the documentation can't be fixed because of the broken nature of the implementation)), OR fix it so that the behaviour is predictable in all situation and the documentation matches, BUT that might break some applications that rely on the old behaviour. ROCK meet HARD PLACE.

Hmmm...more stuff broke. See #1919
We might have to revert...although that leaves us in a very fragile position. We might have to just document the problems and the inconsistencies here, and provide some advice to not rely on this behaviour to try and stop more stuff from breaking in the future :-(

Yeah, I ran into the same issue with Python and MIT Kerberos.
@mattcaswell, have you considered smoke tests with open source projects? Python, PyCA/cryptography and PyCA/PyOpenSSL have extended unit and integration tests for OpenSSL's TLS and crypto libraries. The test suites are stable on major operating systems (Linux, OSX, Windows), too. Simple smoke or pre-release tests should be able to detect bugs before OpenSSL is released.

@tiran, OpenSSL 1.1.1 (i.e. current master) has the concept of external test suites. So far we've only integrated the BoringSSL suite, but it would be nice to integrate others.

@mattcaswell I can help with CPython. Maybe @alex, @reaperhulk and @hynek are interested to add external tests for PyCA/cryptography and PyCA/PyOpenSSL. Ping @frozencemetery, could you help with MIT KRB5?

Take a look here for where we hooked in the Boring suite:
https://github.com/openssl/openssl/blob/master/test/recipes/90-test_external.t
For Boring it was a bit more complicated because we had to have an OpenSSL specific shim to interface between OpenSSL and the BoringSSL test runner. Probably with other external suites we wouldn't need that if they are built to run on OpenSSL in the first place.
See the following for instructions if you want to try out the BoringSSL runner:
https://github.com/openssl/openssl/blob/master/test/README.external
I imagine hooking in a new external suite will be simply a case of extending 90-test_external.t to (somehow) detect whether a specific test is present, if so call some external executable/script, and then something to figure out whether the test succeeded or failed.
I'd love to see some PRs in this area. Once integrated we could then add it to our Travis CI. @ekasper has a WIP PR to do that for Boring (#1888)

It's Perl. I never learned to write Perl. :)
It's rather simple to run Python's ssl tests. We even have a special test helper to just run OpenSSL-related tests. Python doesn't have a configure option for OpenSSL but you can use the usual compiler and linker flags.

cd Python build root
Set CFLAGS=-I${TOP}/include, LDFLAGS=-L${TOP} and LD_RUN_PATH=$TOP
remove build directory to force rebuilding of ssl and hashlib modules
run ./configure && make
run ./python Lib/test/ssltests.py

Step 3 and 4 can be optimized if needed, https://github.com/tiran/multissl/blob/master/multissl.py#L211

In Perl SSL is not in core which is in one way bad but has in this case the advantage that you take any installed Perl you have and then just need to build and test the Net::SSLeay and IO::Socket::SSL modules to get the essential SSL tests. This process can be packed into a small script for automation.  The more advanced tests  we have there test behavior with non-blocking I/O, session ticket sharing between processes, OCSP (live), SNI, ALPN, dynamic certificate creation, upgrade and downgrade between plain text and SSL...  If there is interest I could help to make these tests available as an external test suite.

So are we planning on reverting this?

I think we should revert this change for now and then make sure we can ask the BIOs if it's a permanent error or not.

Can someone take a look at #1931 to see if the new documentation makes sense to them?

Can someone take a look at #1931 to see if the new documentation makes sense to them?

It kind of explains the new API.
But I wish that the documentation would state clearly how to detect EOF. For now I detect it by checking the errno on SSL_ERROR_SYSCALL and if it is 0 (i.e. no error) then I assume that it wasn't actually an error in a system call as one would expect from this error code but that the underlying connection simply got closed (EOF). If this is the correct way it would be good that if it would be explicitly documented this way. Currently the documentation of this part only describes the behavior with UNIX sockets which does not help if one needs to detect EOF  on different OS.
Still, I find the interface of getting a SSL_ERROR_SYSCALL when actually  no  error happened in a syscall unexpected and not intuitive. And it does not help that the documentation claims that this error is thrown on I/O errors because EOF is not an I/O error at all.

It's supposed to explain the old API, in what always worked.
I'm wondering why you want to make a distinction between an unexpected EOF and other errors. The only correct way to close the connection is the SSL_ERROR_ZERO_RETURN.

It's supposed to explain the old API, in what always worked.

The old behavior was explained in the old documentation already, i.e. it was documented that it returns 0 on EOF with unclean shutdown and it did that too. The new documentation does not make this promise anymore but does also not explain how to detect EOF in this case.

I'm wondering why you want to make a distinction between an unexpected EOF and other errors. The only correct way to close the connection is the SSL_ERROR_ZERO_RETURN.

Because in reality I have to deal with peers which don't behave in the only correct way, i.e. which simply close the underlying TCP connection and don't do an SSL shutdown.  But reporting an error all this time to the user is not an option because there were no data lost. Thus I need to distinguish the "bad behavior" case from actual errors.

I can understand that it is nice to make the API more consistent. But I want to make the API also cover the use cases it covered before in an obvious or at least documented way.

Well, we have reverted the previous commit that caused the problem in the first place so you should be back to where we started from a functional perspective. The reality is that the old documentation was incorrect and didn't match what was implemented. It may have worked for some situations with some BIOs, but it was unreliable. Given that this whole area has proven to be very fragile to change I am reluctant to recommend more changes to make it do what the documentation said it did (especially since the documentation was inconsistent across different pages anyway).
The best way to determine whether an EOF has been hit is to ask the underlying BIO with BIO_eof(), i.e. something like:
BIO_eof(SSL_get_rbio())
BIO_eof() is already documented here:
https://www.openssl.org/docs/man1.1.0/crypto/BIO_ctrl.html

@mattcaswell: Thank you for looking into this, and posting this information!
I agree with @noxxi that the documentation of (at least) SSL_read() should also explain this. It is true that BIO_eof() is already documented, and the documentation of SSL_read() is now corrected. However, I find it still lacks this rather essential connection. For example, I would consider it a great improvement if what you suggest in this issue were also mentioned in the documentation of SSL_read(), using for example:

The best way to detect whether EOF has occurred is to ask the underlying BIO using BIO_eof(), using for example BIO_eof(SSL_get_rbio(ssl)).

Without this, users are left in the dark whether using BIO_eof() is even admissible in such cases, assuming they find this function somewhere else in the documentation.

I'm worried that if we suggest to look at that that people think it's a good idea to check that, while I think it's a bad idea. You're setting yourself up for a truncation attack. This is one of the things that was wrong with SSLv2 and was fixed in SSLv3, and you seem to want to reintroduce this at the application level.
The only case I can think of where this check might be useful is that you know the other side is broken, but you have another way to verify that the transfer was complete, for instance because at the application level you can signal that you're done.

@kroeckx: In this direction, the documentation of SSL_read() already contains:

Call SSL_get_error() with the return value ret to find out, whether an error occurred or the connection was shut down cleanly ( SSL_ERROR_ZERO_RETURN ).

It would in my view be well worth adding some of the information you mention above too!
Omitting information about detecting EOF should in my view not be justified by omitting other important information too.

@kroeckx, @mattcaswell : I have now tested whether using the API as suggested lets you detect the difference between a truncation attack and a clean shutdown. As far as I found out, it doesn't:
We get -1 from SSL_read() (or, depending on the OpenSSL version, 0) in both cases, and SSL_get_error() signals SSL_ERROR_SYSCALL in both cases. Further, SSL_get_error() will say 0, whether or not the connection was cleanly shut down.
As far as I can tell from these tests, neither using BIO_eof() nor the sequence suggested in this thread lets us distinguish between a truncation attack and a clean shutdown.

At least s_server seems to come in the SSL_ERROR_RETURN_ZERO case for me on a clean shutdown, and gives an error in case of an unclean shutdown. Can you show some example code?

@kroeckx said:

At least s_server seems to come in the SSL_ERROR_RETURN_ZERO case for me on a clean shutdown, and gives an error in case of an unclean shutdown.

Quite. A clean shutdown is counted as one where a close_notify alert has been received from the peer. If that has happened then SSL_get_error() should return SSL_ERROR_RETURN_ZERO. This is different from SSL_get_error(), giving 0 which @triska says above. A 0 return from SSL_get_error() means SSL_ERROR_NONE (i.e. there has been no error).
@triska said:

As far as I can tell from these tests, neither using BIO_eof() nor the sequence suggested in this thread lets us distinguish between a truncation attack and a clean shutdown.

All BIO_eof() can tell you is whether the BIO has hit EOF. What EOF means is BIO dependant, but for a socket based BIO it would mean the connection has been closed. It tells you nothing about what happened before that closure, i.e. whether a close_notify was received or not.

I should add that you can also use SSL_get_shutdown() to explicitly test whether a connection has been cleanly shutdown or not. This actually tells you slightly different information to SSL_get_error(), i.e. it tells you whether a shutdown alert has been received (i.e. a close_notify or a fatal error alert), or whether we have sent a close_notify ourselves. A connection is only fully and cleanly closed if we have both sent and received a close_notify.
SSL_get_error() will tell you whether a close_notify has been received through SSL_ERROR_RETURN_ZERO. Receipt of a fatal alert will appear as SSL_ERROR_SSL from SSL_get_error() - although it could also mean some other kind of internal error has happened. A SSL_ERROR_SYSCALL return will tell you that some unknown error has occurred in a system call. This could be caused by an unclean shutdown.
So, in summary, if you get a 0 or -1 return from SSL_read()/SSL_write(), you should call SSL_get_error():

If you get back SSL_ERROR_RETURN_ZERO then you know the connection has been cleanly shutdown by the peer. To fully close the connection you may choose to call SSL_shutdown() to send a close_notify back.
If you get back SSL_ERROR_SSL then some kind of internal or protocol error has occurred. More details will be on the SSL error queue. You can also call SSL_get_shutdown(). If this indicates a state of SSL_RECEIVED_SHUTDOWN then you know a fatal alert has been received from the peer (if it had been a close_notify then SSL_get_error() would have returned SSL_ERROR_RETURN_ZERO). SSL_ERROR_SSL is considered fatal - you should not call SSL_shutdown() in this case.
If you get back SSL_ERROR_SYSCALL then some kind of fatal (i.e. non-retryable) error has occurred in a system call. You may be able to get more information from the SSL error queue or you might not. The fatal error could be because the underlying transport has been shutdown unexpectedly (no alert received) or just some other unknown system call error occurred. Calling BIO_eof() at this point will tell you whether the underlying transport has hit EOF (i.e. for a socket BIO the connection has been closed).

@mattcaswell: That's really an excellent overview, and I have used your explanation to make the application work with OpenSSL 1.1.0c as well as earlier versions. Thank you a lot, and I can only recommend to add the essential pieces of this guideline to the documentation of SSL_read().
Further, I have 2 specific questions about this:

Suppose that after detecting a fatal alert (i.e., getting SSL_ERROR_SSL and SSL_get_shutdown() signaling SSL_RECEIVED_SHUTDOWN), I still call SSL_shutdown(). How problematic is this? You say "you should not call SSL_shutdown() in this case", and I can see that it would not make sense, but does it warrant the extra complexity to prevent calling SSL_shutdown() regardless in this situation?
Second, when I try to negotiate a connection, and I get a return value ≤0 from SSL_accept() or SSL_connect(), and further, I get SSL_ERROR_SYSCALL from SSL_get_error(), and ERR_get_error() returns 0, then the code I am maintaining assumes that EOF was unexpectedly encountered during negotiation. How safe is this assumption? Could this also be due to a different error? And conversely, could EOF also be reflected differently? In addition, what are the alternatives I have for distinguishing this case specifically (EOF during session negotiation). I suppose I could test both wbio and rbio for EOF with BIO_eof(), but that likewise does not seem completely reliable to me, because if either of them is no longer needed, then it could have been closed without error.

Suppose that after detecting a fatal alert (i.e., getting SSL_ERROR_SSL and SSL_get_shutdown() signaling SSL_RECEIVED_SHUTDOWN), I still call SSL_shutdown(). How problematic is this? You say "you should not call SSL_shutdown() in this case", and I can see that it would not make sense, but does it warrant the extra complexity to prevent calling SSL_shutdown() regardless in this situation?

The problem here is that as soon as OpenSSL hits a fatal error (for whatever reason), it immediately returns. This might mean that the internal state of the SSL object is not left in a consistent state. If you then start to try and do IO with it then you will get undefined results. In the worst case scenario that could lead to a crash. In most cases it will probably work. In that case, if you call SSL_shutdown(), it will send a close_notify - which just doesn't make sense. Arguably, we should prevent that, so it's not inconceivable that we might change that behaviour at some point. As a general rule though, don't try and continue to do IO on an SSL object that has returned SSL_ERROR_SSL (or for that matter one which has returned SSL_ERROR_SYSCALL).

Second, when I try to negotiate a connection, and I get a return value ≤0 from SSL_accept() or SSL_connect(), and further, I get SSL_ERROR_SYSCALL from SSL_get_error(), and ERR_get_error() returns 0, then the code I am maintaining assumes that EOF was unexpectedly encountered during negotiation. How safe is this assumption? Could this also be due to a different error? And conversely, could EOF also be reflected differently? In addition, what are the alternatives I have for distinguishing this case specifically (EOF during session negotiation). I suppose I could test both wbio and rbio for EOF with BIO_eof(), but that likewise does not seem completely reliable to me, because if either of them is no longer needed, then it could have been closed without error.

If you get SSL_ERROR_SYSCALL from SSL_get_error() it tells you is that there was a fatal non-retryable error in a system call. 99.9% of the time that is going to be because the peer closed the connection down. But even if it isn't, its a fatal non-retryable error so - effectively - the connection is closed, so I think it should be ok to treat it the same way.

So just to clarify, in case of a fatal error (SSL_ERROR_SSL or SSL_ERROR_SYSCALL) you should not call SSL_shutdown(). We should probably at least document that. Possibly we should also make SSL_shutdown() and other functions check the state of the connection before they try to do something.

Could in theory also a fatal error happen in the bidirectional shutdown sequence ?
Is there a difference between a "fatal" SSL_ERROR_SYSCALL and a
non-fatal SSL_ERROR_SYSCALL from SSL_shutdown?
The manual on SSL_shutdown return value 0 says:
"The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional shutdown shall be performed. The output of SSL_get_error(3) may be misleading, as an erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred. "
Is a SSL_ERROR_SSL/SYSCALL with return value -1 more serious than with return value 0 ?

FYI: bio_ssl.c does not follow the rule to avoid SSL_shutdown if previously SSL_ERROR_SSL
or SSL_ERROR_SYSCALL were encountered, it is almost impossible to avoid the SSL_shutdown:
static int ssl_free(BIO *a)
{
    BIO_SSL *bs;

    if (a == NULL)
        return (0);
    bs = BIO_get_data(a);
    if (bs->ssl != NULL)
        SSL_shutdown(bs->ssl);

FYI: bio_ssl.c does not follow the rule to avoid SSL_shutdown if previously SSL_ERROR_SSL
or SSL_ERROR_SYSCALL were encountered, it is almost impossible to avoid the SSL_shutdown:
static int ssl_free(BIO *a)
{
    BIO_SSL *bs;

    if (a == NULL)
        return (0);
    bs = BIO_get_data(a);
    if (bs->ssl != NULL)
        SSL_shutdown(bs->ssl);


libpqxx: 7.7.0 -> 7.8.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/jtv/libpqxx/releases.
meta.description for libpqxx is: "A C++ library to access PostgreSQL databases"
meta.homepage for libpqxx is: "http://pqxx.org/development/libpqxx/"
meta.changelog for libpqxx is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 7.7.4 with grep in /nix/store/y10bs3868fcdymk5byn02lxnngnswgr7-libpqxx-7.7.4
found 7.7.4 in filename of file in /nix/store/y10bs3868fcdymk5byn02lxnngnswgr7-libpqxx-7.7.4

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

12 total rebuild path(s)

12 package rebuild(s)

First fifty rebuilds by attrpath
cloudcompare
grass
hydra_unstable
libpqxx
pdal
pdal_2_3
python310Packages.tiledb
python39Packages.tiledb
qgis
qgis-ltr
tiledb
unityhub

Instructions to test this update (click to expand)

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

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

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

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review took longer than 45m and timed out

Maintainer pings
cc @edolstra for testing.

Result of nixpkgs-review pr 183504 run on x86_64-darwin 1

4 packages marked as broken and skipped:

pdal
pdal_2_3
python310Packages.tiledb
python39Packages.tiledb

2 packages failed to build:

libpqxx
tiledb

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/jtv/libpqxx/releases.
meta.description for libpqxx is: A C++ library to access PostgreSQL databases
meta.homepage for libpqxx is: https://pqxx.org/development/libpqxx/
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 7.7.5 with grep in /nix/store/jqg4bq3mcxdrkzpw6lzwgjl5l3ca7gn0-libpqxx-7.7.5
found 7.7.5 in filename of file in /nix/store/jqg4bq3mcxdrkzpw6lzwgjl5l3ca7gn0-libpqxx-7.7.5

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

75 total rebuild path(s)

75 package rebuild(s)

First fifty rebuilds by attrpath
apacheHttpdPackages.mod_tile
apacheHttpdPackages_2_4.mod_tile
cloudcompare
entwine
gdal
gmt
gplates
grass
haskellPackages.hgdal
hydra_unstable
libLAS
libpqxx
mapcache
mapnik
mapproxy
mapserver
merkaartor
mysql-workbench
octavePackages.mapping
openorienteering-mapper
paraview
pdal
perl534Packages.Tirex
perl536Packages.Tirex
postgresql11JitPackages.postgis
postgresql11Packages.postgis
postgresql12JitPackages.postgis
postgresql12Packages.postgis
postgresql13JitPackages.postgis
postgresql13Packages.postgis
postgresql14JitPackages.postgis
postgresql14Packages.postgis
postgresql15JitPackages.postgis
postgresql15Packages.postgis
postgresqlJitPackages.postgis
postgresqlPackages.postgis
python310Packages.bsuite
python310Packages.cartopy
python310Packages.fiona
python310Packages.folium
python310Packages.gdal
python310Packages.geopandas
python310Packages.osmnx
python310Packages.plotnine
python310Packages.pygmt
python310Packages.python-mapnik
python310Packages.rasterio
python310Packages.rlax
python310Packages.tiledb
python310Packages.wktutils

Instructions to test this update (click to expand)

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

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

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

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review took longer than 45m and timed out

Maintainer pings
cc @edolstra for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/jtv/libpqxx/releases.
meta.description for libpqxx is: A C++ library to access PostgreSQL databases
meta.homepage for libpqxx is: https://pqxx.org/development/libpqxx/
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 7.8.1 with grep in /nix/store/s2nx93lm7adlqhbj48hpnmq115cl4mwa-libpqxx-7.8.1
found 7.8.1 in filename of file in /nix/store/s2nx93lm7adlqhbj48hpnmq115cl4mwa-libpqxx-7.8.1

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

79 total rebuild path(s)

79 package rebuild(s)

First fifty rebuilds by attrpath
apacheHttpdPackages.mod_tile
apacheHttpdPackages_2_4.mod_tile
cloudcompare
entwine
gdal
gmt
gplates
grass
haskellPackages.hgdal
hydra_unstable
libLAS
libpqxx
mapcache
mapnik
mapproxy
mapserver
merkaartor
mysql-workbench
octavePackages.mapping
openorienteering-mapper
paraview
pdal
perl536Packages.Tirex
perl538Packages.Tirex
postgresql11JitPackages.postgis
postgresql11Packages.postgis
postgresql12JitPackages.postgis
postgresql12Packages.postgis
postgresql13JitPackages.postgis
postgresql13Packages.postgis
postgresql14JitPackages.postgis
postgresql14Packages.postgis
postgresql15JitPackages.postgis
postgresql15Packages.postgis
postgresqlJitPackages.postgis
postgresqlPackages.postgis
python310Packages.bsuite
python310Packages.cartopy
python310Packages.django-bootstrap4
python310Packages.fiona
python310Packages.folium
python310Packages.gdal
python310Packages.geopandas
python310Packages.osmnx
python310Packages.plotnine
python310Packages.pygmt
python310Packages.python-mapnik
python310Packages.rasterio
python310Packages.rlax
python310Packages.tiledb

Instructions to test this update (click to expand)

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

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

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

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review took longer than 45m and timed out

Maintainer pings
cc @edolstra for testing.

Merge conflict, please open a new PR.


Fix issue Python Hard

Pull Request Type
What kind of change does this PR introduce?

Solved an issue/task

What is the new behavior?

Implemented the Decision Tree Classifier using NumPy

Merged

This is an automated message from Fork, Commit, Merge [BOT].

Thank you for your contribution! Your pull request has been merged. The files have been reset for the next contributor.
What's next?
If you're looking for more ways to contribute, I invite you to check out our forkcommitmerge.io website repository. The repository contain real issues that you can help to resolve or create some of your own if you see any bugs or want to add new features to the site, etc. You can also check out the Influences section in the README to find more projects similar to this one.
Also please leave a star to this project if you feel it helped you, i would really appreciate it.
I look forward to seeing your contributions!


[GigEV] Is color texture pixel format reversible YCoCg-R? (not custom YCoCg)

Overview

the documentation states that color pixel format is custom YCoCg

https://github.com/photoneo-3d/photoneo-cpp-examples/blob/057428aa15b54234c385712e88e92ddaae90246c/GigEV/README.md?plain=1#L120-L123

what I see after inspecting code is reversible YCoCg-R

YCoCg(-R) -> RGB
In provided sample implementation

omitting the 4:2:0 chroma subsampling part
and focusing on conversion to RGB

Apart from:

trying hard to avoid signed integers
extra check for y == 0
this implements reversible YCoCg-R as defined in many standards

Annotated excerpt from VESA DSC 7.7 Color Space Conversions

Deviation from standard
The only deviation from standard revesible YCoCg-R is:

extra check for y == 0

Question

Could you confirm/deny that pixel format you are using is YCoCg-R, not custom YCoCg?
Is the extra check for y == 0 necessary for some reason? Are you for example marking invalid data with it on sender side?
2.1. Specifically I am interested if you follow the standard formulation of YCoCg-R on the sender side (attached in next post)

RGB -> YCoCg-R
For reference to question 2.1, this is device side (sender)

convert_rgb would be 1
bits_per_component would be 10

VESA DSC 6.1 Color Space Conversions

Thank you @JakubImriskaPhotoneo,
I will relate fragment by fragment
y==0 check

indeed, the extra check of y == 0 is used to protect black pixels, which is needed to be addressed explicitly in the case with chroma subsampling.

Right! I forgot about chroma subsampling and the fact there is only one chroma sample in 2x2 group.
And mapping y==0 doesn't loose other color information that could potentially clash, because there are no other RGB colors that map to y==0 apart from black. In other words y==0 check will not destroy other color information. I understand this now.
Looking at color cuboids vertices there are more such "special channels" that could convey extra information.

Below for YCoCg, but yours/YCoCg-R differs only in scaled Co/Cg axes (source)

Note: The formulas for 16bpc in the last paragraph of the referenced section 6.1 contain the bit shift operator >> which is apparently an error.

Good funny catch.
It is fixed in any subsequent revision of VESA DSC but 16 bits per component is not our case.

10^82 - atoms in universe
2^32768 - this would zero out the ... multiverse?
I always wanted to put my hands on 32768 bit processor...
32768/8=4096 bytes?
They make them this way so that standard 4KB memory page fits in a single integer.

rounding differences, as 1024 - (co + cg) / 2 might differ from -(co - 1024) / 2 - (cg - 1024)/2 in an integer arithmetic,

Truncation differences. As a digression, YCoCg-R is designed in such way that even if truncation happens it reverses back to original values.
This should not differ by more than 1 bit in result.

in the encoding, our Co, Cg differ by 1: Co = cscCo + maxVal, Cg = cscCg + maxVal (which might be suboptimal in terms of information loss).

Interesting. But in sample decoding you are working with delta = 512 = 1024/2 and 2*delta = 1024
Is this intended?
In any case, without putting any more thought in it, this should not differ by more than 1 bit in result.

And we arrive at conclusion.
As I am scaling the final 10 bit RGB values to 8 bit RGB values effectively loosing 2 LSB bits
in my special word your pixel format is equivalent to YCoCg-R aside from y==0 checks.

So the answer is probably nuanced

it is almost VESA YCoCg-R

much closer to it than to YCoCg as you are using same Co ,Cg scaling
has extra protection of black pixels in chroma subsampling

when converting to 8 bit-per-pixel RGB it behaves as YCoCg-R (+ y==0 check)

@bmegli Thanks for summarization. I'll update the related documentation and fix the suboptimality (maxVal -> 1 << bits_per_component) in the encoding.

Thanks!
All my questions were answered and changes on LSbs will not affect my 8 bit-per-pixel RGB word anyway.
I admit I have some trouble discerning subtle shades of 2^30 ~= 1000,000,000 colors


Fixing bug related to compress / decompress on GPU

I added where it is necessary to emphasize in which device the matrix must be created.

Thanks a lot Navid!


Fix cleanup logic in case of ipv6 allocation failure

When creating a network with both IPv4 and IPv6 subnets,
if the allocation of the IPv6 pool fails, the already
reserved IPv4 pool does not get released.

Signed-off-by: Alessandro Boch<EMAIL_ADDRESS>

LGTM


Build: Removed usage of numpy.distutils

This PR replaces the use of numpy.distutils by a ext_modules list in the top level setup.py.
It also imports the build command from setuptools if available (since v62.4.0).
The only remaining dependency to distutils is: from distutils.command.clean import clean.
related to #3574

This looks to work.
Full build for release passes, see https://gitlab.esrf.fr/silx/bob/silx/-/pipelines/85428

I didn't unpin setuptools in pyproject.toml since it is under heavy updates:
https://github.com/silx-kit/silx/blob/bf182fd14eb79b0458220f79a5e3b6d27ed7475d/pyproject.toml#L4
But by not using numpy.distutils anymore, it spares some issues like recently with setuptools v65 and it is a big step towards stopping using distutils.
BTW, this does not prevent us from moving to another tool like meson, but it buys us some more time to do so.

@t20100 an appveyor is failing, related to mask UI. No idea if it's important or not.
I am not able to relaunch it.

Sounds like it fails often and sometime. So let say it's fine.
Probably not related to the build itself.

Yes, CI currently has random failures on appveyor, this is not related to this PR


Vim fails with SIGSEGV on xinput disable

When I disable my mouse using xinput disable "PS/2 Logitech Wheel Mouse" from i3 window manager, gvim stops with this error:
(gvim:27396): Gdk-CRITICAL **: 21:56:31.806: gdk_device_get_n_axes: assertion 'GDK_IS_DEVICE (device)' failed

(gvim:27396): Gdk-CRITICAL **: 21:56:31.806: gdk_event_set_source_device: assertion 'GDK_IS_DEVICE (device)' failed
Vim: Caught deadly signal SEGV

i3-wm config line:
bindsym $mod+F2 exec xinput disable "PS/2 Logitech Wheel Mouse"

Complete git --version:
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jan 20 2019 21:17:42)                                                                                [2/148]
Included patches: 1-1298
Modified by Gentoo-8.0.1298
Compiled by portage@chameleon
Huge version with GTK3 GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +tag_binary
+arabic          +file_in_path    +mouse_sgr       +tag_old_static
+autocmd         +find_in_path    -mouse_sysmouse  -tag_any_white
-autoservername  +float           +mouse_urxvt     -tcl
+balloon_eval    +folding         +mouse_xterm     +termguicolors
+browse          -footer          +multi_byte      +terminal
++builtin_terms  +fork()          +multi_lang      +terminfo
+byte_offset     +gettext         -mzscheme        +termresponse
+channel         -hangul_input    -netbeans_intg   +textobjects
+cindent         +iconv           +num64           +timers
+clientserver    +insert_expand   +packages        +title
+clipboard       +job             +path_extra      +toolbar
+cmdline_compl   +jumplist        -perl            +user_commands
+cmdline_hist    +keymap          +persistent_undo +vertsplit
+cmdline_info    +lambda          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       -python          +viminfo
-cscope          +lispindent      -python3         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con_gui  -lua             +rightleft       +windows
+diff            +menu            -ruby            +writebackup
+digraphs        +mksession       +scrollbind      +X11
+dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     +xim
+emacs_tags      +mouseshape      +startuptime     +xpm
+eval            +mouse_dec       +statusline      -xsmp
+ex_extra        -mouse_gpm       -sun_workshop    +xterm_clipboard
+extra_search    -mouse_jsbterm   +syntax          -xterm_save
   system vimrc file: "/etc/vim/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "/etc/vim/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: x86_64-pc-linux-gnu-gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1
.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include
/fribidi -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpn
g16 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -march=native -O2 -pipe -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: x86_64-pc-linux-gnu-gcc   -Wl,-O1 -L/usr/local/lib -Wl,--as-needed -o gvim   -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -l
gobject-2.0 -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm -lncurses -lelf -lnsl  -lacl -lattr -ldl

The gvim window has to be focused when I disable the mouse.

can you post a stacktrace?

Thread 1 "gvim" received signal SIGSEGV, Segmentation fault.
0x00007ffff7249fa8 in ?? () from /usr/lib64/libgdk-3.so.0
(gdb) bt
#0  0x00007ffff7249fa8 in ?? () from /usr/lib64/libgdk-3.so.0
#1  0x00007ffff7253f32 in ?? () from /usr/lib64/libgdk-3.so.0
#2  0x00007ffff725390f in ?? () from /usr/lib64/libgdk-3.so.0
#3  0x00007ffff721e169 in gdk_display_get_event ()
   from /usr/lib64/libgdk-3.so.0
#4  0x00007ffff7253662 in ?? () from /usr/lib64/libgdk-3.so.0
#5  0x00007ffff5f8b0ef in g_main_context_dispatch ()
   from /usr/lib64/libglib-2.0.so.0
#6  0x00007ffff5f8b358 in ?? () from /usr/lib64/libglib-2.0.so.0
#7  0x00007ffff5f8b40d in g_main_context_iteration ()
   from /usr/lib64/libglib-2.0.so.0
#8  0x0000555555743fcc in gui_mch_wait_for_chars ()
#9  0x000055555573330b in gui_wait_for_chars_or_timer ()
#10 0x00005555557352c1 in gui_wait_for_chars ()
#11 0x000055555571a83d in ui_inchar ()
#12 0x000055555561d6aa in inchar ()
#13 0x000055555561f0a8 in vgetorpeek.part ()
#14 0x00005555556204ea in vgetc ()
#15 0x00005555556207fa in safe_vgetc ()
#16 0x0000555555668903 in normal_cmd ()
#17 0x0000555555760824 in main_loop ()
#18 0x00005555557619fc in vim_main2 ()
---Type <return> to continue, or q <return> to quit---
#19 0x000055555558ad98 in main ()

Gentoo USE flags:
=================================================================
                        Package Settings
=================================================================

app-editors/gvim-8.0.1298::gentoo was built with the following:
USE="acl debug gtk3 nls (-aqua) -cscope -gnome -gtk -lua -luajit -motif -neXt -netbeans -perl -python -racket -ruby (-selinux) -session -tcl" ABI_X86="(64)" PYTHON_SINGLE_TARGET="python3_6 -python2_7 -python3_5" PYTHON_TARGETS="python2_7 python3_6 -python3_5"
CFLAGS="-march=native -O2 -pipe -DDEBUG"
CXXFLAGS="-march=native -O2 -pipe -DDEBUG"

app-editors/vim-8.0.1298::gentoo was built with the following:
USE="X acl debug gpm nls -cscope -lua -luajit -minimal -perl -python -racket -ruby (-selinux) -tcl -terminal -vim-pager" ABI_X86="(64)" PYTHON_SINGLE_TARGET="python3_6 -python2_7 -python3_5" PYTHON_TARGETS="python2_7 python3_6 -python3_5"
CFLAGS="-march=native -O2 -pipe -DDEBUG"
CXXFLAGS="-march=native -O2 -pipe -DDEBUG"

Unfortunately, the stack trace is not really useful without debugging symbols. Can you get the stacktrace with debugging symbols enabled? However it looks like the segfault happens in the gtk library, so I am not sure we can do anything here.

Starting program: /usr/bin/gvim --nofork
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

** (gvim:3218): WARNING **: 17:22:29.237: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[New Thread 0x7fffeb853700 (LWP 3232)]
[New Thread 0x7fffeb052700 (LWP 3233)]
[New Thread 0x7fffea851700 (LWP 3234)]
[New Thread 0x7fffd7fff700 (LWP 3235)]
[Thread 0x7fffea851700 (LWP 3234) exited]

(gvim:3218): Gdk-CRITICAL **: 17:22:31.784: gdk_device_get_n_axes: assertion 'GDK_IS_DEVICE (device)' failed

(gvim:3218): Gdk-CRITICAL **: 17:22:31.784: gdk_event_set_source_device: assertion 'GDK_IS_DEVICE (device)' failed

Thread 1 "gvim" received signal SIGSEGV, Segmentation fault.
0x00007ffff724cbff in gdk_x11_device_manager_xi2_translate_event () from /usr/lib64/libgdk-3.so.0
(gdb) bt
#0  0x00007ffff724cbff in gdk_x11_device_manager_xi2_translate_event () from /usr/lib64/libgdk-3.so.0
#1  0x00007ffff7257100 in _gdk_x11_event_translator_translate () from /usr/lib64/libgdk-3.so.0
#2  0x00007ffff7256cb9 in _gdk_x11_display_queue_events () from /usr/lib64/libgdk-3.so.0
#3  0x00007ffff7220bf1 in gdk_display_get_event () from /usr/lib64/libgdk-3.so.0
#4  0x00007ffff7256842 in gdk_event_source_dispatch () from /usr/lib64/libgdk-3.so.0
#5  0x00007ffff5f8de27 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#6  0x00007ffff5f8e060 in g_main_context_iterate.isra () from /usr/lib64/libglib-2.0.so.0
#7  0x00007ffff5f8e0ed in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#8  0x0000555555740efc in ?? ()
#9  0x000055555573023b in ?? ()
#10 0x00005555557321f1 in ?? ()
#11 0x000055555571778d in ?? ()
#12 0x000055555561d60a in ?? ()
#13 0x000055555561f008 in ?? ()
#14 0x000055555562044a in ?? ()
#15 0x000055555562075a in ?? ()
#16 0x0000555555668863 in ?? ()
#17 0x000055555575d714 in ?? ()
#18 0x000055555575e8ec in ?? ()
#19 0x000055555558acf8 in ?? ()
#20 0x00007ffff4bf4bef in __libc_start_main () from /lib64/libc.so.6
#21 0x000055555558c9ea in ?? ()

So this happens somewhere deep in the GTK code.  It's unlikely caused by Vim.  You may want to try searching for the error message in gtk context.

This is a bug in GTK: https://gitlab.gnome.org/GNOME/gtk/issues/855
@jiwopene thanks for your steps, it helped me reproduce the problem.


Using pd.Series instead of pd.Dataframe

Small change to use Series for x and y values for clarity and simplicity. Code executes equivalently afaict.

Can one of the admins verify this patch?

as a matter of side-interest, I had made some changes to update my code compat with Estimators, but when I when to merge it, it had already been updated lol.

Jenkins, test this please.

Sorry @drpngx I'm not too familiar with this code or with pandas. Maybe @roumposg would know? He made the last big change to the internal version of this.

I am not familiar with Pandas in particular, but I did write this code and tested that it works.
I cannot see what benefit this cl brings in. Yufeng, can you clarify?

@yufengg any thoughts? Should I close this PR or leave it open for you to work it further?

Looks like we can close this, since it doesn't have a clear benefit and we haven't heard from @yufengg.

Oops sorry missed this -- There's a small perf benefit (since you're not constructing a DataSet and then making a Series out of it), but the main reason is for clarity, since it removes the mental step of "Okay we make a Dataset, then select the index column 1 from it, which implicitly makes a Series".
Instead, we just make a Series explicitly. This makes the code more readable and consistent.

LGTM, thanks for the explanation. But I don't think I have the power to approve your change. Perhaps the others can help.

Can one of the admins verify this patch?

@roumposg were you able to run this code and verify that it still works as intended?

Yes, I ran it and verified it works as intended.
On Wed, Aug 2, 2017, 3:45 PM Neal Wu<EMAIL_ADDRESS>wrote:

@roumposg https://github.com/roumposg were you able to run this code
and verify that it still works as intended?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/pull/11221#issuecomment-319819023,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG6Mj-AOPPBsWexyOP6hqIdmEOvoG7Zeks5sUPwHgaJpZM4OLk4H
.

OK, great! Will approve. I checked out the two failing tests and they appear to be unrelated.

@benoitsteiner could you help us merge?


Add set_tag API method to Python SDK

Related issue https://linear.app/serverless/issue/SC-564/python-sdk-custom-tags-api
Description

Add set_tag method to base SDK.
Add custom_tags on TraceSpan.
Add/fix documentation
Use event emitter for captured events, otherwise the set_tag API would have needed to return the error value in case of errors
_captured_events list is removed from the base SDK, consumers can rely on the event being emitted.

Testing done

Unit tested
Integration tests will be updated once set_tag is released.

@medikoo ready for review 🙏


Fix 'Could not find com.facebook.react:react-android' on RN < .71

Description
Fixes #<231>
Checklist

[X] I have tested this on a device/simulator for each compatible OS
[X] I formatted JS and TS files with running yarn lint:fix in the root folder
[X] I have run tests via yarn test in the root folder
[X] I updated the documentation with running yarn generate in the root folder
[X] I mentioned this change in CHANGELOG.md

I also see this on 73.4
Could not find com.facebook.react:react-android:0.73.4.
with android/build.gradle
dependencies {
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin"
classpath('com.android.tools.build:gradle:8.2.2')
classpath 'com.google.gms:google-services:4.3.14'
classpath 'com.google.firebase:firebase-crashlytics-gradle:2.9.2'
classpath("com.facebook.react:react-native-gradle-plugin")
}
and android/app/build.gradle

dependencies {
...
implementation fileTree(dir: "libs", include: ["*.jar"])
implementation "com.facebook.react:react-native:+"  // From node_modules
implementation "com.facebook.react:react-android:0.73.4"
implementation "com.facebook.react:hermes-android:0.73.4"

...}

Something similar was released as v10.0.0-beta.6. Please try if it fixes your problem, if it still exists.


Add chain ID

Codecov Report

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

@@           Coverage Diff           @@
##           master      #61   +/-   ##
=======================================
  Coverage   98.22%   98.22%
=======================================
  Files           5        5
  Lines         282      282
=======================================
  Hits          277      277
  Misses          5        5

Continue to review full report at Codecov.

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


ldap2pg without kerberos

In our organization, the security team does not want to use Kerberos. This approach cause me problem when I try to run a ldapsearch with SASL. I receive this error message:
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (No Kerberos credentials available (default cache: KEYRING:persistent:3646))
Could we use SASL without Kerberos?
Thanks

Hi @mtherio , thanks for reaching.
Configure ldapsearch through ldaprc file and ldap2pg should work too. ldap2pg uses the same library as ldapsearch, ldapwhoami and other ldap utils. See ldap.conf(1) and SASL_MECH option.
Regards,
Étienne

Stale. Please reopen if you have updates.


Invalid session handler trial

build chat-js  target branch
clone this respository and set .env file like below (make sure to check out this branch test/session-handler)

NODE_OPTIONS=--openssl-legacy-provider
STORYBOOK_APP_ID=2D7B4CDB-932F-4082-9B09-A1153792DC8D

npm install from the root repository
go inside of samples/groupchannel and run npm install again

cd `samples/groupchannel` && npm install

run npm run dev
go inside of any channels and click other channels too. After few seconds, you will see below errors from the dev console

Don't need to review this PR. I'm testing with @danney-chun


create server error

i am also getting the same error while running command
knife vcair server create --ssh-password Password1 --image "CentOS64-64bit" --customization-script ./install-linux-vcair.sh --cpus 4 --memory 4096 --node-name centos64
below is the error
DL is deprecated, please use Fiddle
WARN: Unresolved specs during Gem::Specification.reset:
highline (>= 1.6.9, ~> 1.6)
WARN: Clearing out unresolved specs.
Please report a bug if this causes problems.
ERROR: knife encountered an unexpected error
This may be a bug in the 'vcair server create' knife command or plugin
Please collect the output of this command with the -VV option before filing a bug report.
Exception: NoMethodError: undefined method `id' for nil:NilClass
please help me

Closing as a dupe of #23

Thanks cheeseplus, i refered the above #23  but i did not get it what the fix you provide .
i am using chef 11 version and linuz 12 please help me   this is really urgent.

Hi,
Mine issue is not fixed yet. i am still not able to create VM using create
command. i am using linux 12 version and chef 11 version.
Please help me on this .
On Fri, Mar 13, 2015 at 5:42 AM, Seth Thomas<EMAIL_ADDRESS>wrote:

Closed #26 https://github.com/chef-partners/knife-vcair/issues/26.
—
Reply to this email directly or view it on GitHub
https://github.com/chef-partners/knife-vcair/issues/26#event-251452261.

@MayankRShepHertz I closed this issue because an issue for this has already been opened and you've already commented on it. Duplicate issues just make for more noise. As stated in the other thread, folks will be looking at this soon.


Accept int value in head, thin and tail

Related #3278
This PR makes the methods head, thin and tail for both DataArray and Dataset accept a single integer value as a parameter. If no parameter is given, then it defaults to 5.

[x] Tests added
[x] Passes black . && mypy . && flake8

Any other feedback before we merge? (Errors are unrelated)

@max-sixty I think the typing errors are due to changing the Any to int and actually finding slice.

I would try to include value in the message, too, which can often be a
useful hint about what went wrong, e.g., “expected positive integer for
dimension ‘x’, got -1”
On Fri, Sep 13, 2019 at 8:56 PM Gerardo Rivera<EMAIL_ADDRESS>wrote:

@DangoMelon commented on this pull request.
In xarray/core/dataset.py
https://github.com/pydata/xarray/pull/3298#discussion_r324411117:

     indexers = either_dict_or_kwargs(indexers, indexers_kwargs, "head")

   for v in indexers.values():

       if not isinstance(v, int):

           raise TypeError("indexer value must be an integer")

       elif v < 0:

           raise ValueError("indexer value must be positive")

Hmmm, Something along these lines maybe?
"expected integer as indexer value, found type %r for dim %r" % (type(v), k)
and
"expected positive integer as indexer value for dim %r" % k
The k and v come from iterating over indexers.items()
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/pydata/xarray/pull/3298?email_source=notifications&email_token=AAJJFVVWFOWK5LYL33Z6Q4DQJROHDA5CNFSM4IVADGGKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCEXTGGA#discussion_r324411117,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJJFVRJWPWIG5XBDWEPRMLQJROHDANCNFSM4IVADGGA
.

Here's a solution to the mypy issue:
diff --git a/xarray/core/dataset.py b/xarray/core/dataset.py
index 1d762114..ee4ebf4d 100644
--- a/xarray/core/dataset.py
+++ b/xarray/core/dataset.py
@@ -2046,8 +2046,8 @@ class Dataset(Mapping, ImplementsDatasetReduce, DataWithCoords):
                 raise TypeError("indexer value must be an integer")
             elif v < 0:
                 raise ValueError("indexer value must be positive")
-        indexers = {k: slice(val) for k, val in indexers.items()}
-        return self.isel(indexers)
+        indexers_slices = {k: slice(val) for k, val in indexers.items()}
+        return self.isel(indexers_slices)

     def tail(
         self,
@@ -2087,11 +2087,11 @@ class Dataset(Mapping, ImplementsDatasetReduce, DataWithCoords):
                 raise TypeError("indexer value must be an integer")
             elif v < 0:
                 raise ValueError("indexer value must be positive")
-        indexers = {
+        indexers_slices = {
             k: slice(-val, None) if val != 0 else slice(val)
             for k, val in indexers.items()
         }
-        return self.isel(indexers)
+        return self.isel(indexers_slices)

     def thin(
         self,
@@ -2134,8 +2134,8 @@ class Dataset(Mapping, ImplementsDatasetReduce, DataWithCoords):
                 raise ValueError("indexer value must be positive")
             elif v == 0:
                 raise ValueError("step cannot be zero")
-        indexers = {k: slice(None, None, val) for k, val in indexers.items()}
-        return self.isel(indexers)
+        indexers_slices = {k: slice(None, None, val) for k, val in indexers.items()}
+        return self.isel(indexers_slices)

     def broadcast_like(
         self, other: Union["Dataset", "DataArray"], exclude: Iterable[Hashable] = None

@shoyer I hope it's much clear now, I tried to phrase what you suggested.
@max-sixty That did the trick!
Thank you both for your suggestions.

thanks @DangoMelon !

@DangoMelon - thanks for your contribution. This will get used a lot!


[BUG] Close Opensearch RestHighLevelClient in OpenSearchClientRefresher on shutdown and initialization failure

Describe the bug
When the data prepper pipeline Opensearch Sink initialization fails, data prepper continuously retries to recreate Opensearch client and OpenSearchClientRefresher (refresh credentials). Looks like on initialization failure, we only close Opensearch client and not OpenSearchClientRefresher (this has another reference to Opensearch client). These unclosed Opensearch clients are consuming threads and are resulting in OOM.
To Reproduce
If the Opensearch Sink credentials or data/network access policy is not configured correctly, data prepper continuously retries to recreate Opensearch client. Below OOM exception is seen in the logs.
 ERROR org.opensearch.dataprepper.pipeline.common.PipelineThreadPoolExecutor - Pipeline [cdc-pipeline] process worker encountered a fatal exception, cannot proceed further
java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached
	at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]

Expected behavior
The Opensearch Sink/Source should gracefully close the opened connection.
Code Reference
Should add close method to OpenSearchClientRefresher to close OpenSearchClient and call it here.

https://github.com/opensearch-project/data-prepper/pull/4758

@dinujoh , Do you think that #4758 will resolve this? Is there anything missing that you see?


Remove live demo

Hi, your readme looks well documented, Good Job! But you need to make a little adjustment you can just remove the live demo from the list table of contents because there is no live demo link or content in your document.

Alright! thanks for sighting the issue. I have corrected it


Homepage ScrollControl does not work properly in Safari browser

🧐 버그 설명

📸 스크린샷

@DrAugus Thank you for reporting the issue.
To help us better understand the bug, could you please provide a detailed explanation and screenshots?
Your cooperation would be greatly appreciated.

https://user-images.githubusercontent.com/34206897/229719423-8364979d-7a59-4a91-a137-a7b4b6040b9a.mov


[WIP] Implement SA1138: Indent elements correctly

Fixes #2025

Current coverage is 92.85%

Merging #2034 into master will decrease coverage by -0.55% as of bfdbea1

@@            master   #2034   diff @@
======================================
  Files          561     565      +4
  Stmts        35587   36695   +1108
  Branches      2283    2361     +78
  Methods
======================================
+ Hit          33240   34074    +834
- Partial        749     771     +22
- Missed        1598    1850    +252

Review entire Coverage Diff as of bfdbea1

Powered by Codecov. Updated on successful CI builds.

:memo: Currently SA1138UnitTests.TestAttributeListAsync demonstrates an incorrect indentation behavior that should be fixed.

Note for myself: things noticed during testing:

[ ] Attributes are indented too far
[ ] Contents of nested using indented too far
[ ] Contents of nested if / else if indented too far

Hi. Any updates on this pull request? It would be great to land this one since it is really important for code readability. Thanks!


Added MF namespace, updated API, added deprecations

Exports a new global MF and updates the model fragments API (as discussed in #11) in preparation for v1.0. Adds deprecation warnings for all outdated APIs
Changes:
DS.ModelFragment → MF.Fragment
DS.hasOneFragment → MF.fragment
DS.hasManyFragments → MF.fragmentArray
Support for non-fragment hasManyFragment properties has been removed from MF.fragmentArray and replaced with a new property MF.array, which supports transforms:
export default DS.Model.extend({
  things: MF.array('string'),
  stuff: MF.array('my-custom-transform')
});

Full API
Closes #11
Closes #13

:+1:


Update iterable_dataset.py

close https://github.com/huggingface/datasets/issues/7297

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


Add pv argument to get_all_pvs that allows a glob pattern.

Pull Request Test Coverage Report for Build 366

5 of 5 (100.0%)  changed or added relevant lines in 1 file are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.3%) to 97.391%

Files with Coverage Reduction
New Missed Lines
%

aa/ca.py
2
95.35%

Totals

Change from base Build 364:
-0.3%

Covered Lines:
560

Relevant Lines:
575

💛  - Coveralls

It looks sensible enough. I will test it, and assuming it works, rebase and merge.

OK I think I know the reason why you postponed this. I get the same test failure that you do.
Adding the extra argument here makes this the only use with more than one URL parameter. Because of the non-deterministic ordering in dictionaries, two successive calls to AaRestClient._construct_url output the parameters in different orders. This causes the test to fail.
My preferred way to fix this would be to change _construct_url to accept an OrderedDict for the URL parameters, instead of using **kwargs.
I guess at the time you questioned whether this was worth it. I think it probably is so I'll go ahead and do it for neatness' sake.

That sounds right. Deterministic URLs make sense I think.

Thanks, looks good.


Add a new weight / Edit a weight

changed title from Add a new weight to Add a new weight{+ / Edit a weight+}


add target_group_arn_suffixes output

This is helpful in adding cloud watch monitor(s) for a given number of healthy instances:
From the module invocation, where we specify the list of target groups:
target_groups = "${list     (map       ("name", "${var.app1}", "backend_protocol", "HTTP", "backend_port", "8080"       ),     (map       ("name", "${var.app2}", "backend_protocol", "HTTP", "backend_port", "80"       )     )   )}"
Cloudwatch usage:
`resource "aws_cloudwatch_metric_alarm" "app1_unhealthy_hosts" {
alarm_name          = "${var.app1}-unhealthy-host"
comparison_operator = "LessThanThreshold"
datapoints_to_alarm = "3"
evaluation_periods  = "5"
metric_name         = "HealthyHostCount"
namespace           = "AWS/ApplicationELB"
period              = "60"
statistic           = "Maximum"
threshold           = "2"
dimensions {
TargetGroup   = "${element(module.alb.target_group_arn_suffixes, 0)}"
LoadBalancer  = "${module.alb.load_balancer_arn_suffix}"
}
alarm_description = "${var.environment} ${var.service} ${var.app1} instance(s) failing health checks."
alarm_actions      = [
"${module.notify_slack.this_slack_topic_arn}",
"${aws_sns_topic.pagerduty.arn}"
]
ok_actions      = [
"${module.notify_slack.this_slack_topic_arn}",
"${aws_sns_topic.pagerduty.arn}"
]
}`

Hey @jeff-everett 👋  Funny seeing you here, former teamy.
Everything looks good with your change. Thanks for the contribution and I'll cut a release with it shortly.


[feature request] flyout for microphone volume

a flyout which can change default/current microphone volume or every microphone volume.

I did actually think of implementing this as well; though it would be a relatively large feature (requiring to build up and render that flyout window, and undoubtedly a lot of details making sure that works correctly on all systems).
One alternative I started implementing a few weeks back (but didn't yet finish) was an option that always forces the microphone volume to 100%; as that is usually the most sane default given that most apps using microphones these days have already implemented their own volume level / automatic gain control (no doubt due to Windows not doing it themselves). Would that also satisfy your use case, or do you need to set the microphone volume to specific levels?

second variant, to set microphone volume to specific level. windows has options to change mics volumes.

An option to set the recording volume to 100% has been added in the just released v0.3.0. See the README for details on how to use it.

nice this is good. can i modify the request? using this app alot time. a better ideea is to change volume via scroll for default microphone.


Textbox Hint

I have the same issue like issue reported in "Possible bug using TextBox hints #251"
and the other issue in the group box showed in modal popup the text of the hint and value are in white color, i attach two images with the issue

What version you on?

The latest version (MaterialDesignThemes <IP_ADDRESS>8), i installed from nuget packages

The problem was solved, I thought I had the latest version installed but it was not, I update and resolved, but now also shows the drop down like the image below, also would like to know how to change the background color from dark/light to blue or to another color


Segmentation Fault with invalid type name

With this code, which mis-spells DNode to DNODE:
(def foo (macro extern ((name (p char)) (t DNODE))))

When attempting to compile, it segfaults:
% dalec foo.dt
zsh: segmentation fault  dalec foo.dt

However once I was able to give the correct error message randomly:
% dalec foo.dt -vv
dalec: invalid option -- v
dalec: invalid option -- v
foo.dt:1:44: error: type not in scope: 'DNODE'

Other times with the same (invalid) command line options not so much:
% dalec foo.dt -vv
dalec: invalid option -- v
dalec: invalid option -- v
zsh: segmentation fault  dalec foo.dt -vv

So I think this is probably uninitialized memory that is sometimes 0 and sometimes just garbage. Should be fairly easy to find using the sanitizers in llvm since the compiler is written in C++.

Thanks for the bug report, it turned out to be right on the money.

Great! Thanks for fixing it. Would hate to debug a larger codebase with "Segmentation fault" as my only error message :)


Make license package more resilient to unexpected output

What type of PR is this?
/kind bug
/kind cleanup
What this PR does / why we need it:
This PR improves the licensing code to be more resilient when encountering unexpected license tags in the
classifier output. Since v2.0.0, [the classifier will now return a pseudo license tag when finding copyright information] in files. This caused our libraries to return an error when scanning files.
It also fixes another bug where the secondary license list was lost after scanning and classifying a file.
The verbosity of the licensing code has now been reduced to make it more understandable.
Which issue(s) this PR fixes:
Part of https://github.com/kubernetes/release/issues/2729
Special notes for your reviewer:
/assign @jeremyrickard @xmudrii @cpanato
Does this PR introduce a user-facing change?
- Fixed a bug where the secondary license list returned by the classifier was not being returned
- Improved the licensing code to be more resilient to unexpected output from the classifier
- Licensing output is now less verbose. Use `--log-level=debug` to see all messages

The CLI runs. It should run in krel too as we're not changing anything that affects it. But I can only test it once this merges and we can run a build using someones branch

/lgtm
/approve

@cpanato let me know when we can lift the hold to test krel :rocket:

@cpanato let me know when we can lift the hold to test krel :rocket:

@cpanato let me know when we can lift the hold to test krel :rocket:

/unhold

doing the update in krel and testing


Pathway Image empty

Breaking case: http://mj3cheun.github.io/pathways-search.html#/pathway?uri=http%3A%2F%2Fidentifiers.org%2Freactome%2FR-HSA-69541
The downloaded file is empty.

I assume you are talking about the PNG download? I am aware of this. For some reason, if you pass in the full pathway option, cytoscapejs throws an error resulting in an empty file for some pathways. Interestingly enough, the screenshot button still functions fine. Of course I have been unable to prove it, but I have found that NCI pathways have this problem but other datasources don't. I am doing investigating for the moment.

I also see this for (Reactome) 'Signaling by BMP'

Ok good to know. So far I have seen the problem with several NCI pathways but haven't seen it with a couple INOH pathways. Trying to find common threads between all the broken pathways.

@d2fong Error message and example of a pathway that has this problem

Dylan recently changed SBGN-renderer, when beta is back up test to see if it fixed the problem.

I doubt any of the recent changes I made fixed this problem.

@maxkfranz
https://github.com/cytoscape/cytoscape.js/blob/unstable/src/extensions/renderer/canvas/export-image.js#L15
This function seems to have thrown a NS_ERROR_FAILURE error when exporting one of the pathways to an image in Manfred's app.

Each browser has a max file size limit.  If it's too large, you have to use a smaller file (jpg or lower dpi).

Ok thanks Max, that solved the problem.
Fixed in commit 4733dbad33c1cdd7e9b4cf796a5fc87208a7849e. Dropped scaling from 10 -> 5, which should be enough overhead for most reasonable pathways. Will drop it lower if size becomes an issue again.

See https://github.com/cytoscape/cytoscape.js/issues/1775


Set path column to not null

Migration to ensure no more path nil values make it into the database
following bugfix #37.
cc @benilovj
Taiga

:+1:


misplaced LICENSE file

You state in the README that this is licensed under the AGPL, but clicking that link takes you to a 404 page. I do not see a license file in the repo right now.
Could you please add a license? Thanks in advance!

Ah, thanks! Nice catch!
When I merged v2, I accidentally removed it! 🥲