Support for module http2?

Hi, I would like to know if Express 5.0 will have support for http2:
https://github.com/molnarg/node-http2
I was reading a bit and I noticed that exist a problem with http2 module:
https://github.com/molnarg/node-http2/issues/100
I have tested in local and the problem continues:
https://github.com/jabrena/CloudFoundryLab/blob/master/Node_HelloWorld_http2_express/index.js
It this issue in the roadmap?
Does exist another alternative to run a express application with http2?
Many thanks in advance.
Juan Antonio

I have just tested with latest release alpha (5.0.0-alpha.2) and the problem continues:

/*jslint node: true*/
"use strict";

var fs = require('fs');
var http2 = require('http2');
var express = require('express');

var app = express();
app.get('/', function (req, res) {
    console.log(req.headers);

    res.header('Content-type', 'text/html');
    return res.end('
Hello, Secure World!
');
});

var options = {
    key: fs.readFileSync('./certificate/localhost.key'),
    cert: fs.readFileSync('./certificate/localhost.crt')
};
var port = process.env.VCAP_APP_PORT || 8080;
http2.createServer(options, app).listen(port);

Hi! o answer your question, yes, it is a known issue, and no, has not yet been addressed. We have a link back to that referenced http2 issue (noted in https://github.com/molnarg/node-http2/issues/100#issuecomment-111549799) already to track this as well as it listed in our Express 5 roadmap (#2237):

Support non-core HTTP prototypes (e.g. http2, shot and others)

The 5.0 alpha 2 does not work because it has not been addressed yet. It is not a simple fix at all, and any help you want to provide toward this as part of a PR is much appreciated!

In addition, if all you want to do is replicate the Express routing with http2, the module router (https://github.com/pillarjs/router) is the actual Express 4.x router, extracted into it's own module and will work just fine with http2:
/*jslint node: true*/
"use strict";

var finalhandler = require('finalhandler');
var fs = require('fs');
var http2 = require('http2');
var Router = require('router');

var router = new Router();
router.get('/', function (req, res) {
    console.log(req.headers);

    res.setHeader('Content-type', 'text/html');
    return res.end('
Hello, Secure World!
');
});

var options = {
    key: fs.readFileSync('./certificate/localhost.key'),
    cert: fs.readFileSync('./certificate/localhost.crt')
};
var port = process.env.VCAP_APP_PORT || 8080;
http2.createServer(options, app).listen(port);

function app(req, res) {
    router(req, res, finalhandler(req, res));
}

Hi @dougwilson, if you provide some technical documentation to check that classes, I could help you to begin fixing this issue. Tomorrow, I will test the alternative.

Hi @jabrena , I'm not sure what kind of technical documentation you are looking for. All Express documentation is located at http://expressjs.com/ and anything technical is gathered from reading the JavaScript source code of Express.

No problem, will try to check this part:
If it is var originalPrototype = req.__proto__; req.__proto__ = app.request; app.request.__proto__ = originalPrototype;

it is a clue from a comment in:
https://github.com/molnarg/node-http2/issues/100
Besides, I will compare current router with the router that runs with http2
Juan Antonio

@jabrena , @dougwilson why not https://github.com/indutny/node-spdy?

With this module you can create HTTP2 / SPDY

AFAIK node-spdy already works with Express 4

:+1:

Pretty interesting!!!
I will test next week.
@victorherraiz @isuriv

I can confirm node-spdy works fine, I'm using it. It doesn't however let you use HTTP/2 push promises very easily with Express. I made an issue about this at #2781.

I think having http2 out of the box is perhaps a little out of scope of express itself?

I think having http2 out of the box is perhaps a little out of scope of express itself?

It may be, but I interpret this issue as the fact that it's impossible to even use the http2 module. Technically Express doesn't really do HTTP out of the box, unless you count the single app.listen entry point. HTTP support is, in the general sense, done with http.createServer(app), and that should work for the http2 and other modules for this issue to be considered closed.

The problem to me is not that express is not compatible with the spdy module. They are compatible, it all works. However, if I want to use HTTP2 push promises, all the goodies of Express, like .static and sendFile become unusable. I cannot connect their logic to the push promise stream.

Hi @ronkorving, perhaps open a new issue in regards to that problem? I don't want to loose sight on the issue brought up in the original post on the issue, which is specifically about working with http2. Please open a new issue, providing as much detail into the problem as you can, so we can reproduce and see what we can figure out.

You mean like #2781 ? :)

Ah, yep :) But I don't know anything about node-spdy and there is no code for me to even play with. Without a full way to reproduce and the technical details of the issue, I'm not sure how much help I can be on that issue. @jonathanong replied to you and he has used that module in the past, but I don't think anyone else has and I forgot that even existed. Can you fill out the issue some more for use non-spdy users?

No problem :+1:

@dougwilson - I went down your path of using router module and ran into issues with not being able to use res.sendFile anymore. I ended up extracting all the sendFile logic and reworking it as a thunk that works just like serveStatic (supports all sendFile options). I published it as serve-file module, may come in handy to anyone that ran into the same issues as me. I tested it on http2 / spdy with router and had no issues:
import serveFile from 'serve-file'

app.use('/my-file.txt', serveFile('path/to/my-file.txt'))

I quite curious if initialising your express application as follows would be enough to resolve the problems. It seems to be enough to get a very simple application working:
ar express = require('.');
var http2 = require('http2');

express.request.__proto__ = http2.IncomingMessage.prototype;
express.response.__proto__ = http2.ServerResponse.prototype;

var app = express();

OK, so the main problem I found with https://github.com/expressjs/express/issues/2761#issuecomment-216912022 is that it doesn't handle HTTP/1.1 fallback properly. Since the prototype used here is statically set to the http2 prototype, it is incorrect when fallback happens to HTTP/1.1 resulting in a TypeError (attempt to call push() on undefined).
About a month ago, shortly before I posted the above comment I had implemented a change in my local express to dynamically fix-up the prototype chain and that's where I stumbled on express.request and express.response -- my patch broke that functionality.
However, I just ran the acme-air for Node.js benchmark app on my patched express and it seems to fix the problem with falling back. I'm going to see if I can reinstate the express.request and express.response API, or something that provides similar functionality and push a branch for wider testing.

I've cleaned the patch up some and changed it a bit in light of some issues that I found during further testing -- I discovered app.request and app.response, the application level equivalents of express.request and express.response and changed the patch to preserve similar functionality.
The approach the patch takes is to resolve inheritance issues by mixing in the express API object instead of inserting it into the inheritance chain. Combined with lazily caching the prototype chain for each protocol that is used, a correct prototype chain can be kept for each request.
I the latest implementation the mixed-in API objects are also stored in the cache to avoid performing the mixin afresh on every request. This means there is a cache entry for each app and protocol combination in the system.
I have renamed the app-level and express-level request and response objects to make it clear they are now mixins. This may not be desirable as it will break code that modifies these API objects (for example, to add methods), however, it may be a good idea if the difference in behaviour would cause subtle bugs.
Since these mixins are performed once and cached thereafter, modifications to the API objects have no effect after the first request is handled (for a given app/protocol combination). This could be improved by providing a mechanism for dirtying the cache.
The branch (based on 5.0):
https://github.com/tunniclm/express/tree/http2_with_dynamic_insertion2
Comparison with expressjs/express#5.0:
https://github.com/expressjs/express/compare/5.0...tunniclm:http2_with_dynamic_insertion2

Is http/2 still on roadmap?

@tunniclm, your work looks promising. Any reason why you're not submitting it as a pull request towards the official repository?

@asbjornu There's also PR #3730, which could add http/2 support for express and maybe it will be merged.

For anyone saying just use spdy, HTTP/2 is an actual standard now. SPDY is not. On top of that spdy makes heavy use of private internal functions in node.  It is broken and expected not to be fixed for any node version >= 11.1
IMO supporting the actual native http2 should be the current direction that express takes

as @nwgh actually mentioned in https://github.com/molnarg/node-http2/issues/100 on Aug 9, 2016 already:

[...] just to note, spdy is dead.

So the SPDY package is no longer maintained, and due to a bug in the handle-thing dependency even broken when running with node > 11.1 (see https://github.com/nodejs/node/issues/24097). So going for SPDY is clearly no longer an option! The only way forward for express supporting HTTP/2 is the Node.js http2 package.
Is there any update on the progress about this? It'd be a bummer if Express 5 would not provide any HTTP/2 support! Thanks.

for anybody Googling:
internal/buffer.js:940
class FastBuffer extends Uint8Array {}
^

RangeError: Invalid typed array length: -4095
    at new Uint8Array (<anonymous>)
    at new FastBuffer (internal/buffer.js:940:1)
    at Handle.onStreamRead [as onread] (internal/stream_base_commons.js:181:19)
    at Stream.<anonymous> (/Users/bros/repos/redacted/node_modules/handle-thing/lib/handle.js:88:10)
    at Stream.emit (events.js:215:7)
    at endReadableNT (/Users/bros/repos/redacted/node_modules/spdy-transport/node_modules/readable-stream/lib/_stream_readable.js:1077:12)
    at processTicksAndRejections (internal/process/task_queues.js:80:21)
error Command failed with exit code 1.

Has anybody got anything to push to fix http/2 issues? log in #4112 for 4.17.1/5.0/5.x... we tried pillerjs/router as a fix but still leaves is in a broken state. many modules and process explicitly depend on express being available and have only managed to work through a fraction of them to remove express dependencies.

fyi, the spdy/handle-thing issue has been fixed: https://github.com/spdy-http2/handle-thing/pull/13
I was just able to start an HTTP/2 server using spdy and express on Node v12.6.0 and v13.11.0. I get an ugly console message (node:48680) [DEP0066] DeprecationWarning: OutgoingMessage.prototype._headers is deprecated but apart from that, spdy seems to work with the latest Node.js versions again.

This gist can help somebody who needs to use spdy only for development http2 server with express js

Any news on this ?

It's disheartening that the (essentially) de-facto Nodejs server framework still - in 2020 - has no support for http2. Experimental support for http3 was just added in Nodejs 15, so this is way behind the curve.

Experimental support for http3 was recently added in Nodejs 15, would be awesome to see Express catch up on this.

@RandomByte don't give people reasons to use hacks instead of standards
@csvan agreed. it's honestly mind boggling that the largest node server framework refuses to support the probably most important new standard to web protocols

@SampsonCrowley don't think I would go as far as to say they are refusing to do it, but Express has been getting alarmingly little development in relation to its importance for several years now. 5.0 has been in alpha for almost 7 (!!!!!) years, and overall development has been moving at glacial speeds.
I wonder if they overall goal for Express is simply to be a legacy fallback framework now. The competition is already way ahead of it on almost all fronts except for adoption, and the only argument to use it is really how rich the ecosystem around it is.

@SampsonCrowley don't think I would go as far as to say they are refusing to do it

I view the fact that there has been literally zero progress after 5 YEARS as a refusal to prioritize the evolving standards of both nodejs and the web itself
I've since decided to use fastify for any node projects because of the complete lack of ANY progress for support for the CORE of the web

Some one has created a bridge to make this work in all scenarios,
https://javascript.plainenglish.io/serving-hello-world-with-http2-and-express-js-4dd0ffe76860

node-spdy does not work for static files on node >=15; link to issue.

Any progress here on the http/2 front?

so many years, there is no progress...


[Event Request] table 246 "Requisition Line" - OnBeforeValidateQuantityBase

We would like to add a new event OnBeforeValidateQuantityBase in the following trigger:
    field(5408; "Quantity (Base)"; Decimal)
    {
        Caption = 'Quantity (Base)';
        DecimalPlaces = 0 : 5;

        trigger OnValidate()
        var
            IsHandled: Boolean;
        begin
            IsHandled := false;
            //OnBeforeValidateQuantityBase(Rec, IsHandled); A200F0000.Event18.03.o
            OnBeforeValidateQuantityBase(Rec, xRec, CurrFieldNo, CurrentFieldNo, IsHandled); //A200F0000.Event18.03.n
            if IsHandled then
                exit;

            TestField("Prod. Order No.", '');
            TestField("Qty. per Unit of Measure", 1);
            Validate(Quantity, "Quantity (Base)");
        end;
    }

Event Signature:
[IntegrationEvent(false, false)]
local procedure OnBeforeValidateQuantityBase(var RequisitionLine: Record "Requisition Line"; xRequisitionLine: Record "Requisition Line"; CallingFieldNo: Integer; CurrentCallingFieldNo: Integer; var IsHandled: Boolean)
begin
    //A200F0000.Event18.03 Parameter xRequisitionLine, CallingFieldNo, CurrentCallingFieldNo
end;

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


support/docs for json mode

does the gem support json mode as outlined here:
https://ai.google.dev/gemini-api/docs/api-overview#curl_4

The docs here work, but the confusing part is that json mode only works when using Vertex.
https://ai.google.dev/gemini-api/docs/api-overview#json
i.e.
client.generate_content(
  contents: messages,
  system_instructions: options[:system_message],
  generation_config: { response_mime_type: "application/json" }
)

@weilandia Thanks for testing and sharing! Yeah, I couldn't find examples/documentation to make it work outside of Vertex.
@jtoy Thanks for opening the issue! I added examples and documentation in the README:

JSON Format Responses

JSON Schema

Using JSON schema in the generation config only works with Pro.
Since I imagine most people will end up here to use Flash (it seems to me that as of now the only good reason to use Pro is context size) it might be good to highlight that schemas are only supported with pro.
"While Gemini 1.5 Flash models only accept a text description of the JSON schema you want returned, the Gemini 1.5 Pro models let you pass a schema object (or a Python type equivalent), and the model output will strictly follow that schema. This is also known as controlled generation or constrained decoding."

@weilandia Here's my test results:

❌ Does not support JSON mode.
🟡 Supports JSON mode but not Schema.
✅ Supports JSON mode and Schema.
🔒 I don't have access to the model.

Model
Vertex AI
Generative Language

gemini-pro-vision
❌
🔒

gemini-pro
🟡
❌

gemini-1.5-pro-preview-0514
✅
🔒

gemini-1.5-pro-preview-0409
✅
🔒

gemini-1.5-pro
✅
❌

gemini-1.5-flash-preview-0514
🟡
🔒

gemini-1.5-flash
🟡
❌

gemini-1.0-pro-vision-latest
🔒
🔒

gemini-1.0-pro-vision-001
❌
🔒

gemini-1.0-pro-vision
❌
🔒

gemini-1.0-pro-latest
🔒
❌

gemini-1.0-pro-002
🟡
🔒

gemini-1.0-pro-001
❌
❌

gemini-1.0-pro
🟡
❌

gemini-ultra
🔒
🔒

gemini-1.0-ultra
🔒
🔒

gemini-1.0-ultra-001
🔒
🔒

It works with generative language on gemini-1.5-pro on the v1beta endpoint right now.

It works with generative language on gemini-1.5-pro on the v1beta endpoint right now with JSON schema.

I get a HTTP 400 response when doing this through the gem. The same request via curl seems to work fine though, and returns only JSON.
Either way, seems like Vertex is not needed for JSON responses anymore, but seems there is an issue in this gem stopping it from working?

It works for me when I set version: "v1beta" under credentials. Seems the default v1 does not support JSON responses.


brew install bowtie-json-schema/tap/bowtie fails

installing fails for me with the output below.
I don't speak python or pip, so i am a bit lost here :-(
Any idea what might be the problem? Any log file or something else I can check?

HEAD is now at 7a5156c Fix the artifact extension...
==> Installing bowtie from bowtie-json-schema/tap
==> python3.11 -m venv --system-site-packages /usr/local/Cellar/bowtie/0.84.2/libexec
==> /usr/local/Cellar/bowtie/0.84.2/libexec/bin/pip install -v --no-deps --no-binary :all: --use-feature=no-binary-enable-wheel-cache --ignore-installed /private/tmp/bowtie--aiodocker-20230513-61758-1l1jdgg/aiodocker-0.21.0
==> /usr/local/Cellar/bowtie/0.84.2/libexec/bin/pip install -v --no-deps --no-binary :all: --use-feature=no-binary-enable-wheel-cache --ignore-installed /private/tmp/bowtie--aiohttp-20230513-61758-19qeabh/aiohttp-3.8.4
==> /usr/local/Cellar/bowtie/0.84.2/libexec/bin/pip install -v --no-deps --no-binary :all: --use-feature=no-binary-enable-wheel-cache --ignore-installed /private/tmp/bowtie--aiosignal-20230513-61758-h6idw7/aiosignal-1.3.1
==> /usr/local/Cellar/bowtie/0.84.2/libexec/bin/pip install -v --no-deps --no-binary :all: --use-feature=no-binary-enable-wheel-cache --ignore-installed /private/tmp/bowtie--async-timeout-20230513-61758-cak53i/async-timeout-4.0.2
==> /usr/local/Cellar/bowtie/0.84.2/libexec/bin/pip install -v --no-deps --no-binary :all: --use-feature=no-binary-enable-wheel-cache --ignore-installed /private/tmp/bowtie--attrs-20230513-61758-1ftk1gx/attrs-22.2.0
==> /usr/local/Cellar/bowtie/0.84.2/libexec/bin/pip install -v --no-deps --no-binary :all: --use-feature=no-binary-enable-wheel-cache --ignore-installed /private/tmp/bowtie--certifi-20230513-61758-fn4bzt/certifi-2022.12.7
==> /usr/local/Cellar/bowtie/0.84.2/libexec/bin/pip install -v --no-deps --no-binary :all: --use-feature=no-binary-enable-wheel-cache --ignore-installed /private/tmp/bowtie--cffi-20230513-61758-vv3dlu/cffi-1.15.1
==> /usr/local/Cellar/bowtie/0.84.2/libexec/bin/pip install -v --no-deps --no-binary :all: --use-feature=no-binary-enable-wheel-cache --ignore-installed /private/tmp/bowtie--charset-normalizer-20230513-61758-1nfh9y2/charset-normalizer-3.1.0
==> /usr/local/Cellar/bowtie/0.84.2/libexec/bin/pip install -v --no-deps --no-binary :all: --use-feature=no-binary-enable-wheel-cache --ignore-installed /private/tmp/bowtie--click-20230513-61758-2fnmh5/click-8.1.3
==> /usr/local/Cellar/bowtie/0.84.2/libexec/bin/pip install -v --no-deps --no-binary :all: --use-feature=no-binary-enable-wheel-cache --ignore-installed /private/tmp/bowtie--cryptography-20230513-61758-2ijm2d/cryptography-40.0.1
Last 15 lines from /Users/hauner/Library/Logs/Homebrew/bowtie/11.pip:

  × Building wheel for cryptography (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> See above for output.

  note: This error originates from a subprocess, and is likely not a problem with pip.
  full command: /usr/local/Cellar/bowtie/0.84.2/libexec/bin/python3.11 /usr/local/Cellar/bowtie/0.84.2/libexec/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py build_wheel /private/tmp/tmpaqdcs8eu
  cwd: /private/tmp/bowtie--cryptography-20230513-61758-2ijm2d/cryptography-40.0.1
  Building wheel for cryptography (pyproject.toml): finished with status 'error'
  ERROR: Failed building wheel for cryptography
Failed to build cryptography
ERROR: Could not build wheels for cryptography, which is required to install pyproject.toml-based projects

[notice] A new release of pip is available: 23.0.1 -> 23.1.2
[notice] To update, run: python3.11 -m pip install --upgrade pip

If reporting this issue please do so at (not Homebrew/brew or Homebrew/homebrew-core):
  https://github.com/bowtie-json-schema/homebrew-tap/issues

running pip update:
% python3.11 -m pip install --upgrade pip
Requirement already satisfied: pip in /usr/local/lib/python3.11/site-packages (23.1.2)

Hi! Sorry for the trouble -- that error is basically saying that compiling something (a C extension) failed.
There's likely multiple things that went wrong, since ideally/usually I think you should be getting a pre-compiled version of that that doesn't require compiling on your machine... but alas.
Can you share the contents of /Users/hauner/Library/Logs/Homebrew/bowtie/11.pip which should have the full error message? What's there isn't quite enough to tell what the real problem is yet.

wow, that's long :-)
I tried to run pip install cryptography, but it did not help.
I see some network errors in the log, might be that I'am not fast enough to confirm my firewalls (Little Snitch) connection request...  Not sure, this is usually not a problem.
2023-05-13 18:12:20 +0000

/usr/local/Cellar/bowtie/0.84.2/libexec/bin/pip
install
-v
--no-deps
--no-binary
:all:
--use-feature=no-binary-enable-wheel-cache
--ignore-installed
/private/tmp/bowtie--cryptography-20230513-67865-85vqc1/cryptography-40.0.1

Using pip 23.0.1 from /usr/local/Cellar/bowtie/0.84.2/libexec/lib/python3.11/site-packages/pip (python 3.11)
Processing /private/tmp/bowtie--cryptography-20230513-67865-85vqc1/cryptography-40.0.1
  Installing build dependencies: started
  Running command pip subprocess to install build dependencies
  DEPRECATION: --no-binary currently disables reading from the cache of locally built wheels. In the future --no-binary will not influence the wheel cache. pip 23.1 will enforce this behaviour change. A possible replacement is to use the --no-cache-dir option. You can use the flag --use-feature=no-binary-enable-wheel-cache to test the upcoming behaviour. Discussion can be found at https://github.com/pypa/pip/issues/11453
  Collecting setuptools!=60.9.0,>=40.6.0
    Using cached setuptools-67.7.2.tar.gz (2.5 MB)
    Getting requirements to build wheel: started
    Getting requirements to build wheel: finished with status 'done'
    Installing backend dependencies: started
    Installing backend dependencies: finished with status 'done'
    Preparing metadata (pyproject.toml): started
    Preparing metadata (pyproject.toml): finished with status 'done'
  Collecting wheel
    Using cached wheel-0.40.0.tar.gz (96 kB)
    Installing build dependencies: started
    Installing build dependencies: finished with status 'done'
    Getting requirements to build wheel: started
    Getting requirements to build wheel: finished with status 'done'
    Preparing metadata (pyproject.toml): started
    Preparing metadata (pyproject.toml): finished with status 'done'
  Collecting cffi>=1.12
    Downloading cffi-1.15.1.tar.gz (508 kB)
       ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 508.5/508.5 kB 2.5 MB/s eta 0:00:00
    Preparing metadata (setup.py): started
    Preparing metadata (setup.py): finished with status 'done'
  Collecting setuptools-rust>=0.11.4
    Downloading setuptools-rust-1.6.0.tar.gz (296 kB)
       ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 296.4/296.4 kB 2.5 MB/s eta 0:00:00
    Installing build dependencies: started
    Installing build dependencies: finished with status 'done'
    Getting requirements to build wheel: started
    Getting requirements to build wheel: finished with status 'done'
    Installing backend dependencies: started
    Installing backend dependencies: finished with status 'done'
    Preparing metadata (pyproject.toml): started
    Preparing metadata (pyproject.toml): finished with status 'done'
  Collecting pycparser
    Downloading pycparser-2.21.tar.gz (170 kB)
       ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 170.9/170.9 kB 2.4 MB/s eta 0:00:00
    Preparing metadata (setup.py): started
    Preparing metadata (setup.py): finished with status 'done'
  Collecting semantic-version<3,>=2.8.2
    Downloading semantic_version-2.10.0.tar.gz (52 kB)
       ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 52.3/52.3 kB 2.1 MB/s eta 0:00:00
    Preparing metadata (setup.py): started
    Preparing metadata (setup.py): finished with status 'done'
  Collecting typing-extensions>=<IP_ADDRESS>
    Downloading typing_extensions-4.5.0.tar.gz (52 kB)
       ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 52.4/52.4 kB 2.0 MB/s eta 0:00:00
    Installing build dependencies: started
    Installing build dependencies: finished with status 'done'
    Getting requirements to build wheel: started
    Getting requirements to build wheel: finished with status 'done'
    Preparing metadata (pyproject.toml): started
    Preparing metadata (pyproject.toml): finished with status 'done'
  Building wheels for collected packages: wheel, setuptools-rust, typing-extensions, setuptools
    Building wheel for wheel (pyproject.toml): started
    Building wheel for wheel (pyproject.toml): finished with status 'done'
    Created wheel for wheel: filename=wheel-0.40.0-py3-none-any.whl size=64545 sha256=72bc033eef8bc7934fb74f93024e9e56a7f7f14b7c30a3adf612bc3b2100d7cb
    Stored in directory: /private/tmp/bowtie-20230513-67865-b0fr4m/.brew_home/Library/Caches/pip/wheels/bc/70/cf/cf52a35bf9c8cf13b1c1988213097a65bae84a5a14b492a6bb
    Building wheel for setuptools-rust (pyproject.toml): started
    Building wheel for setuptools-rust (pyproject.toml): finished with status 'done'
    Created wheel for setuptools-rust: filename=setuptools_rust-1.6.0-py3-none-any.whl size=23960 sha256=29adb4d56a85e0e611fd2c4720e32b6164042f2bd50db49ec5ba95392ce51cd1
    Stored in directory: /private/tmp/bowtie-20230513-67865-b0fr4m/.brew_home/Library/Caches/pip/wheels/66/29/77/8f85e73accc24db683a1e5c4cda7310bc02ecab9485277e535
    Building wheel for typing-extensions (pyproject.toml): started
    Building wheel for typing-extensions (pyproject.toml): finished with status 'done'
    Created wheel for typing-extensions: filename=typing_extensions-4.5.0-py3-none-any.whl size=27736 sha256=8368056a717ace190bb1cc79e4f57f84ed5ae153ebee0757805537d14782b89c
    Stored in directory: /private/tmp/bowtie-20230513-67865-b0fr4m/.brew_home/Library/Caches/pip/wheels/f5/bf/e3/ef05ff5fbb094548aef48e4e81f3c60f68c0697f436a967084
    Building wheel for setuptools (pyproject.toml): started
    Building wheel for setuptools (pyproject.toml): finished with status 'done'
    Created wheel for setuptools: filename=setuptools-67.7.2-py3-none-any.whl size=1093536 sha256=85b51c6140ce1cafb36cde7e4b18416d4d1f6cc6f05d4f2e3ce4ac2de9a9b1dc
    Stored in directory: /private/tmp/bowtie-20230513-67865-b0fr4m/.brew_home/Library/Caches/pip/wheels/8f/15/a5/cf36a621ae8bb3378224a209c0b25c046798c7e08e876e0087
  Successfully built wheel setuptools-rust typing-extensions setuptools
  Installing collected packages: wheel, typing-extensions, setuptools, semantic-version, pycparser, setuptools-rust, cffi
    DEPRECATION: semantic-version is being installed using the legacy 'setup.py install' method, because the '--no-binary' option was enabled for it and this currently disables local wheel building for projects that don't have a 'pyproject.toml' file. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/11451
    Running setup.py install for semantic-version: started
    Running setup.py install for semantic-version: finished with status 'done'
    DEPRECATION: pycparser is being installed using the legacy 'setup.py install' method, because the '--no-binary' option was enabled for it and this currently disables local wheel building for projects that don't have a 'pyproject.toml' file. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/11451
    Running setup.py install for pycparser: started
    Running setup.py install for pycparser: finished with status 'done'
    DEPRECATION: cffi is being installed using the legacy 'setup.py install' method, because the '--no-binary' option was enabled for it and this currently disables local wheel building for projects that don't have a 'pyproject.toml' file. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/11451
    Running setup.py install for cffi: started
    Running setup.py install for cffi: finished with status 'done'
  Successfully installed cffi-1.15.1 pycparser-2.21 semantic-version-2.10.0 setuptools-67.7.2 setuptools-rust-1.6.0 typing-extensions-4.5.0 wheel-0.40.0

  [notice] A new release of pip is available: 23.0.1 -> 23.1.2
  [notice] To update, run: python3.11 -m pip install --upgrade pip
  Installing build dependencies: finished with status 'done'
  Getting requirements to build wheel: started
  Running command Getting requirements to build wheel
  running egg_info
  writing src/cryptography.egg-info/PKG-INFO
  writing dependency_links to src/cryptography.egg-info/dependency_links.txt
  writing requirements to src/cryptography.egg-info/requires.txt
  writing top-level names to src/cryptography.egg-info/top_level.txt
  reading manifest file 'src/cryptography.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  no previously-included directories found matching 'docs/_build'
  warning: no previously-included files found matching 'vectors'
  warning: no previously-included files matching '*' found under directory 'vectors'
  warning: no previously-included files matching '*' found under directory '.github'
  warning: no previously-included files found matching 'release.py'
  warning: no previously-included files found matching '.readthedocs.yml'
  warning: no previously-included files found matching 'ci-constraints-requirements.txt'
  warning: no previously-included files found matching 'mypy.ini'
  adding license file 'LICENSE'
  adding license file 'LICENSE.APACHE'
  adding license file 'LICENSE.BSD'
  adding license file 'LICENSE.PSF'
  writing manifest file 'src/cryptography.egg-info/SOURCES.txt'
  Getting requirements to build wheel: finished with status 'done'
  Preparing metadata (pyproject.toml): started
  Running command Preparing metadata (pyproject.toml)
  running dist_info
  creating /private/tmp/pip-modern-metadata-t5ts0mga/cryptography.egg-info
  writing /private/tmp/pip-modern-metadata-t5ts0mga/cryptography.egg-info/PKG-INFO
  writing dependency_links to /private/tmp/pip-modern-metadata-t5ts0mga/cryptography.egg-info/dependency_links.txt
  writing requirements to /private/tmp/pip-modern-metadata-t5ts0mga/cryptography.egg-info/requires.txt
  writing top-level names to /private/tmp/pip-modern-metadata-t5ts0mga/cryptography.egg-info/top_level.txt
  writing manifest file '/private/tmp/pip-modern-metadata-t5ts0mga/cryptography.egg-info/SOURCES.txt'
  reading manifest file '/private/tmp/pip-modern-metadata-t5ts0mga/cryptography.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  no previously-included directories found matching 'docs/_build'
  warning: no previously-included files found matching 'vectors'
  warning: no previously-included files matching '*' found under directory 'vectors'
  warning: no previously-included files matching '*' found under directory '.github'
  warning: no previously-included files found matching 'release.py'
  warning: no previously-included files found matching '.readthedocs.yml'
  warning: no previously-included files found matching 'ci-constraints-requirements.txt'
  warning: no previously-included files found matching 'mypy.ini'
  adding license file 'LICENSE'
  adding license file 'LICENSE.APACHE'
  adding license file 'LICENSE.BSD'
  adding license file 'LICENSE.PSF'
  writing manifest file '/private/tmp/pip-modern-metadata-t5ts0mga/cryptography.egg-info/SOURCES.txt'
  creating '/private/tmp/pip-modern-metadata-t5ts0mga/cryptography-40.0.1.dist-info'
  Preparing metadata (pyproject.toml): finished with status 'done'
Building wheels for collected packages: cryptography
  Building wheel for cryptography (pyproject.toml): started
  Running command Building wheel for cryptography (pyproject.toml)
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.macosx-13-x86_64-cpython-311
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography
  copying src/cryptography/__init__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography
  copying src/cryptography/utils.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography
  copying src/cryptography/__about__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography
  copying src/cryptography/exceptions.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography
  copying src/cryptography/fernet.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat
  copying src/cryptography/hazmat/__init__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat
  copying src/cryptography/hazmat/_oid.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/x509
  copying src/cryptography/x509/oid.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/x509
  copying src/cryptography/x509/ocsp.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/x509
  copying src/cryptography/x509/general_name.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/x509
  copying src/cryptography/x509/__init__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/x509
  copying src/cryptography/x509/extensions.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/x509
  copying src/cryptography/x509/name.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/x509
  copying src/cryptography/x509/base.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/x509
  copying src/cryptography/x509/certificate_transparency.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/x509
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends
  copying src/cryptography/hazmat/backends/__init__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/_serialization.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/cmac.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/_asymmetric.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/__init__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/_cipheralgorithm.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/poly1305.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/constant_time.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/keywrap.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/hmac.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/hashes.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives
  copying src/cryptography/hazmat/primitives/padding.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings
  copying src/cryptography/hazmat/bindings/__init__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/x448.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/backend.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/ec.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/ciphers.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/aead.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/rsa.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/dh.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/cmac.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/__init__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/utils.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/poly1305.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/ed25519.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/dsa.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/decode_asn1.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/hmac.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/ed448.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  copying src/cryptography/hazmat/backends/openssl/hashes.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/backends/openssl
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/kdf
  copying src/cryptography/hazmat/primitives/kdf/__init__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/kdf
  copying src/cryptography/hazmat/primitives/kdf/scrypt.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/kdf
  copying src/cryptography/hazmat/primitives/kdf/pbkdf2.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/kdf
  copying src/cryptography/hazmat/primitives/kdf/hkdf.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/kdf
  copying src/cryptography/hazmat/primitives/kdf/x963kdf.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/kdf
  copying src/cryptography/hazmat/primitives/kdf/kbkdf.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/kdf
  copying src/cryptography/hazmat/primitives/kdf/concatkdf.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/kdf
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/twofactor
  copying src/cryptography/hazmat/primitives/twofactor/totp.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/twofactor
  copying src/cryptography/hazmat/primitives/twofactor/__init__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/twofactor
  copying src/cryptography/hazmat/primitives/twofactor/hotp.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/twofactor
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/serialization
  copying src/cryptography/hazmat/primitives/serialization/__init__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/serialization
  copying src/cryptography/hazmat/primitives/serialization/pkcs12.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/serialization
  copying src/cryptography/hazmat/primitives/serialization/pkcs7.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/serialization
  copying src/cryptography/hazmat/primitives/serialization/ssh.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/serialization
  copying src/cryptography/hazmat/primitives/serialization/base.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/serialization
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/ciphers
  copying src/cryptography/hazmat/primitives/ciphers/algorithms.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/ciphers
  copying src/cryptography/hazmat/primitives/ciphers/aead.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/ciphers
  copying src/cryptography/hazmat/primitives/ciphers/__init__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/ciphers
  copying src/cryptography/hazmat/primitives/ciphers/modes.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/ciphers
  copying src/cryptography/hazmat/primitives/ciphers/base.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/ciphers
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/asymmetric
  copying src/cryptography/hazmat/primitives/asymmetric/x448.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/asymmetric
  copying src/cryptography/hazmat/primitives/asymmetric/ec.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/asymmetric
  copying src/cryptography/hazmat/primitives/asymmetric/rsa.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/asymmetric
  copying src/cryptography/hazmat/primitives/asymmetric/dh.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/asymmetric
  copying src/cryptography/hazmat/primitives/asymmetric/__init__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/asymmetric
  copying src/cryptography/hazmat/primitives/asymmetric/types.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/asymmetric
  copying src/cryptography/hazmat/primitives/asymmetric/utils.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/asymmetric
  copying src/cryptography/hazmat/primitives/asymmetric/ed25519.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/asymmetric
  copying src/cryptography/hazmat/primitives/asymmetric/dsa.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/asymmetric
  copying src/cryptography/hazmat/primitives/asymmetric/ed448.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/asymmetric
  copying src/cryptography/hazmat/primitives/asymmetric/x25519.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/asymmetric
  copying src/cryptography/hazmat/primitives/asymmetric/padding.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/primitives/asymmetric
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/openssl
  copying src/cryptography/hazmat/bindings/openssl/__init__.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/openssl
  copying src/cryptography/hazmat/bindings/openssl/_conditional.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/openssl
  copying src/cryptography/hazmat/bindings/openssl/binding.py -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/openssl
  running egg_info
  writing src/cryptography.egg-info/PKG-INFO
  writing dependency_links to src/cryptography.egg-info/dependency_links.txt
  writing requirements to src/cryptography.egg-info/requires.txt
  writing top-level names to src/cryptography.egg-info/top_level.txt
  reading manifest file 'src/cryptography.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  no previously-included directories found matching 'docs/_build'
  warning: no previously-included files found matching 'vectors'
  warning: no previously-included files matching '*' found under directory 'vectors'
  warning: no previously-included files matching '*' found under directory '.github'
  warning: no previously-included files found matching 'release.py'
  warning: no previously-included files found matching '.readthedocs.yml'
  warning: no previously-included files found matching 'ci-constraints-requirements.txt'
  warning: no previously-included files found matching 'mypy.ini'
  adding license file 'LICENSE'
  adding license file 'LICENSE.APACHE'
  adding license file 'LICENSE.BSD'
  adding license file 'LICENSE.PSF'
  writing manifest file 'src/cryptography.egg-info/SOURCES.txt'
  /private/tmp/pip-build-env-xtom0jim/overlay/lib/python3.11/site-packages/setuptools/command/build_py.py:201: _Warning: Package 'cryptography.hazmat.bindings._rust' is absent from the `packages` configuration.
  !!

          ********************************************************************************
          ############################
          # Package would be ignored #
          ############################
          Python recognizes 'cryptography.hazmat.bindings._rust' as an importable package[^1],
          but it is absent from setuptools' `packages` configuration.

          This leads to an ambiguous overall configuration. If you want to distribute this
          package, please make sure that 'cryptography.hazmat.bindings._rust' is explicitly added
          to the `packages` configuration field.

          Alternatively, you can also rely on setuptools' discovery methods
          (for example by using `find_namespace_packages(...)`/`find_namespace:`
          instead of `find_packages(...)`/`find:`).

          You can read more about "package discovery" on setuptools documentation page:

          - https://setuptools.pypa.io/en/latest/userguide/package_discovery.html

          If you don't want 'cryptography.hazmat.bindings._rust' to be distributed and are
          already explicitly excluding 'cryptography.hazmat.bindings._rust' via
          `find_namespace_packages(...)/find_namespace` or `find_packages(...)/find`,
          you can try to use `exclude_package_data`, or `include-package-data=False` in
          combination with a more fine grained `package-data` configuration.

          You can read more about "package data files" on setuptools documentation page:

          - https://setuptools.pypa.io/en/latest/userguide/datafiles.html

          [^1]: For Python, any directory (with suitable naming) can be imported,
                even if it does not contain any `.py` files.
                On the other hand, currently there is no concept of package data
                directory, all directories are treated like packages.
          ********************************************************************************

  !!
    check.warn(importable)
  /private/tmp/pip-build-env-xtom0jim/overlay/lib/python3.11/site-packages/setuptools/command/build_py.py:201: _Warning: Package 'cryptography.hazmat.bindings._rust.openssl' is absent from the `packages` configuration.
  !!

          ********************************************************************************
          ############################
          # Package would be ignored #
          ############################
          Python recognizes 'cryptography.hazmat.bindings._rust.openssl' as an importable package[^1],
          but it is absent from setuptools' `packages` configuration.

          This leads to an ambiguous overall configuration. If you want to distribute this
          package, please make sure that 'cryptography.hazmat.bindings._rust.openssl' is explicitly added
          to the `packages` configuration field.

          Alternatively, you can also rely on setuptools' discovery methods
          (for example by using `find_namespace_packages(...)`/`find_namespace:`
          instead of `find_packages(...)`/`find:`).

          You can read more about "package discovery" on setuptools documentation page:

          - https://setuptools.pypa.io/en/latest/userguide/package_discovery.html

          If you don't want 'cryptography.hazmat.bindings._rust.openssl' to be distributed and are
          already explicitly excluding 'cryptography.hazmat.bindings._rust.openssl' via
          `find_namespace_packages(...)/find_namespace` or `find_packages(...)/find`,
          you can try to use `exclude_package_data`, or `include-package-data=False` in
          combination with a more fine grained `package-data` configuration.

          You can read more about "package data files" on setuptools documentation page:

          - https://setuptools.pypa.io/en/latest/userguide/datafiles.html

          [^1]: For Python, any directory (with suitable naming) can be imported,
                even if it does not contain any `.py` files.
                On the other hand, currently there is no concept of package data
                directory, all directories are treated like packages.
          ********************************************************************************

  !!
    check.warn(importable)
  copying src/cryptography/py.typed -> build/lib.macosx-13-x86_64-cpython-311/cryptography
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/_rust
  copying src/cryptography/hazmat/bindings/_rust/__init__.pyi -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/_rust
  copying src/cryptography/hazmat/bindings/_rust/_openssl.pyi -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/_rust
  copying src/cryptography/hazmat/bindings/_rust/asn1.pyi -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/_rust
  copying src/cryptography/hazmat/bindings/_rust/ocsp.pyi -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/_rust
  copying src/cryptography/hazmat/bindings/_rust/pkcs7.pyi -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/_rust
  copying src/cryptography/hazmat/bindings/_rust/x509.pyi -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/_rust
  creating build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/_rust/openssl
  copying src/cryptography/hazmat/bindings/_rust/openssl/__init__.pyi -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/_rust/openssl
  copying src/cryptography/hazmat/bindings/_rust/openssl/x25519.pyi -> build/lib.macosx-13-x86_64-cpython-311/cryptography/hazmat/bindings/_rust/openssl
  warning: build_py: byte-compiling is disabled, skipping.

  running build_ext
  running build_rust
  cargo rustc --lib --message-format=json-render-diagnostics --manifest-path src/rust/Cargo.toml --release -v --features pyo3/abi3-py36 pyo3/extension-module --crate-type cdylib -- -C link-args=-undefined dynamic_lookup<EMAIL_ADDRESS>      Updating crates.io index
  warning: spurious network error (2 tries remaining): failed to connect to github.com: Bad file descriptor; class=Os (2)
  warning: spurious network error (1 tries remaining): failed to connect to github.com: Bad file descriptor; class=Os (2)
  error: Unable to update registry `crates-io`

  Caused by:
    failed to fetch `https://github.com/rust-lang/crates.io-index`

  Caused by:
    failed to connect to github.com: Bad file descriptor; class=Os (2)

      =============================DEBUG ASSISTANCE=============================
      If you are seeing a compilation error please try the following steps to
      successfully install cryptography:
      1) Upgrade to the latest pip and try again. This will fix errors for most
         users. See: https://pip.pypa.io/en/stable/installing/#upgrading-pip
      2) Read https://cryptography.io/en/latest/installation/ for specific
         instructions for your platform.
      3) Check our frequently asked questions for more information:
         https://cryptography.io/en/latest/faq/
      4) Ensure you have a recent Rust toolchain installed:
         https://cryptography.io/en/latest/installation/#rust

      Python: 3.11.3
      platform: macOS-13.2-x86_64-i386-64bit
      pip: n/a
      setuptools: 67.7.2
      setuptools_rust: 1.6.0
      rustc: 1.69.0 (84c898d65 2023-04-16) (built from a source tarball)
      =============================DEBUG ASSISTANCE=============================

  error: `cargo rustc --lib --message-format=json-render-diagnostics --manifest-path src/rust/Cargo.toml --release -v --features 'pyo3/abi3-py36 pyo3/extension-module' --crate-type cdylib -- -C 'link-args=-undefined dynamic_lookup<EMAIL_ADDRESS>failed with code 101
  error: subprocess-exited-with-error

  × Building wheel for cryptography (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> See above for output.

  note: This error originates from a subprocess, and is likely not a problem with pip.
  full command: /usr/local/Cellar/bowtie/0.84.2/libexec/bin/python3.11 /usr/local/Cellar/bowtie/0.84.2/libexec/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py build_wheel /private/tmp/tmpehwjl547
  cwd: /private/tmp/bowtie--cryptography-20230513-67865-85vqc1/cryptography-40.0.1
  Building wheel for cryptography (pyproject.toml): finished with status 'error'
  ERROR: Failed building wheel for cryptography
Failed to build cryptography
ERROR: Could not build wheels for cryptography, which is required to install pyproject.toml-based projects

[notice] A new release of pip is available: 23.0.1 -> 23.1.2
[notice] To update, run: python3.11 -m pip install --upgrade pip

HOMEBREW_VERSION: 4.0.17
ORIGIN: https://github.com/Homebrew/brew.git
HEAD: c0f8068573bbf886fdc78d3f9daca54d53e7e49e
Last commit: 5 days ago
Core tap origin: https://github.com/Homebrew/homebrew-core
Core tap HEAD: d73afd035b70971f895d014a4297b6f906e95e7c
Core tap last commit: 5 weeks ago
Core tap branch: master
Core tap JSON: 13 May 18:10 UTC
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: /private/tmp/com.apple.launchd.TNiFh2bISF/org.macosforge.xquartz:0
HOMEBREW_MAKE_JOBS: 4
HOMEBREW_NO_BOOTSNAP: set
Homebrew Ruby: 2.6.10 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: quad-core 64-bit kabylake
Clang: 14.0.3 build 1403
Git: 2.40.1 => /usr/local/bin/git
Curl: 7.86.0 => /usr/bin/curl
macOS: 13.2-x86_64
CLT: N/A
Xcode: 14.3

HOMEBREW_CC: clang
HOMEBREW_CXX: clang++
MAKEFLAGS: -j4
CMAKE_PREFIX_PATH: /usr/local/opt/openssl@1.1:/usr/local/opt/ncurses:/usr/local/opt/readline:/usr/local/opt/sqlite:/usr/local
CMAKE_INCLUDE_PATH: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk/usr/include/apache2:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers
CMAKE_LIBRARY_PATH: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries
CMAKE_FRAMEWORK_PATH: /usr/local/opt/python@3.11/Frameworks:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk/System/Library/Frameworks
PKG_CONFIG_PATH: /usr/local/opt/capstone/lib/pkgconfig:/usr/local/opt/pcre2/lib/pkgconfig:/usr/local/opt/glib/lib/pkgconfig:/usr/local/opt/gmp/lib/pkgconfig:/usr/local/opt/libidn2/lib/pkgconfig:/usr/local/opt/libtasn1/lib/pkgconfig:/usr/local/opt/nettle/lib/pkgconfig:/usr/local/opt/p11-kit/lib/pkgconfig:/usr/local/opt/openssl<EMAIL_ADDRESS>PKG_CONFIG_LIBDIR: /usr/lib/pkgconfig:/usr/local/Homebrew/Library/Homebrew/os/mac/pkgconfig/13
HOMEBREW_GIT: git
HOMEBREW_SDKROOT: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.sdk
ACLOCAL_PATH: /usr/local/share/aclocal
PATH: /usr/local/Homebrew/Library/Homebrew/shims/mac/super:/usr/local/opt/rust/bin:/usr/local/opt/capstone/bin:/usr/local/opt/pcre2/bin:/usr/local/opt/gettext/bin:/usr/local/opt/glib/bin:/usr/local/opt/libidn2/bin:/usr/local/opt/libtasn1/bin:/usr/local/opt/nettle/bin:/usr/local/opt/p11-kit/bin:/usr/local/opt/openssl@1.1/bin:/usr/local/opt/libevent/bin:/usr/local/opt/gnutls/bin:/usr/local/opt/jpeg-turbo/bin:/usr/local/opt/libpng/bin:/usr/local/opt/ncurses/bin:/usr/local/opt/vde/bin:/usr/local/opt/lz4/bin:/usr/local/opt/xz/bin:/usr/local/opt/zstd/bin:/usr/local/opt/qemu/bin:/usr/local/opt/podman/bin:/usr/local/opt/sqlite/bin:/usr/local/opt/python@3.11/bin:/usr/local/opt/python@3.11/libexec/bin:/usr/bin:/bin:/usr/sbin:/sbin

So the actual error there is the line(s) talking about "    failed to fetch https://github.com/rust-lang/crates.io-index`"` -- are you on some sort of corporate network or something with a firewall?
 warning: spurious network error (2 tries remaining): failed to connect to github.com: Bad file descriptor; class=Os (2)
  warning: spurious network error (1 tries remaining): failed to connect to github.com: Bad file descriptor; class=Os (2)

The error seems to be saying something is making you unable to reach GitHub fully correctly. A restart may also help. But yeah it seems likely network related from that output.

Yep using a firewall (Little Snitch). Usually it brings up a popup, I confirm the connection and everything works.
I tried to temporarily disable it but it still failed with the same error. So strange... never had this issue before. But looks like the issue is on my side.
Thanks for pointing me to the 11.pip log file :-)

oh, I managed to create a permanent deny rule for cargo. :-(
It works now, sorry for the noise ;-)

Glad to hear it works :)


Compilation failure on stackage for autodocodec-schema & autodocodec-openapi3 - caused by autodocodec-<IP_ADDRESS>

Unfortunately I couldn't explain what causes the issue ... I'll disable the packages on stackage as a temporary solution (to not block further nightly builds).
autodocodec-schema-<IP_ADDRESS>-351f2eba904cbec211fba1e444b111ecb19e7907dc1e2932b03ba314cb337a32/src/Autodocodec/Schema.hs:380:77: error: [GHC-10283]
           • Could not deduce ‘Coercible output0 input1’
               arising from a use of ‘OptionalKeyWithDefaultCodec’
             from the context: (Eq value, Coercible input1 value,
                                Coercible output1 value)
               bound by a pattern with constructor:
                          OptionalKeyWithOmittedDefaultCodec :: forall value input output.
                                                                (Eq value, Coercible input value,
                                                                 Coercible output value) =>
                                                                Text
                                                                -> ValueCodec value value
                                                                -> value
                                                                -> Maybe Text
                                                                -> Codec
                                                                     (Data.Aeson.KeyMap.KeyMap JSON.Value)
                                                                     input
                                                                     output,
                        in a \case alternative
               at src/Autodocodec/Schema.hs:380:7-62
             ‘input1’ is a rigid type variable bound by
               the type signature for:
                 goObject :: forall input1 output1.
                             ObjectCodec input1 output1 -> State (Set Text) ObjectSchema
               at src/Autodocodec/Schema.hs:369:5-73
           • In the first argument of ‘goObject’, namely
               ‘(OptionalKeyWithDefaultCodec k c defaultValue mDoc)’
             In the expression:
               goObject (OptionalKeyWithDefaultCodec k c defaultValue mDoc)
             In a \case alternative:
                 OptionalKeyWithOmittedDefaultCodec k c defaultValue mDoc
                   -> goObject (OptionalKeyWithDefaultCodec k c defaultValue mDoc)
           • Relevant bindings include
               goObject :: ObjectCodec input1 output1
                           -> State (Set Text) ObjectSchema
                 (bound at src/Autodocodec/Schema.hs:370:5)
           |
       380 |       OptionalKeyWithOmittedDefaultCodec k c defaultValue mDoc -> goObject (OptionalKeyWithDefaultCodec k c defaultValue mDoc)
           |

and basically the same error in the other package
autodocodec-openapi3-<IP_ADDRESS>-edfda14b60bbc6f518fbecabca7fee31ec662623d0669d1f13ccbcf9d75536f4/src/Autodocodec/OpenAPI/Schema.hs:176:80: error: [GHC-10283]
           • Could not deduce ‘Coercible output0 input’                                                                                arising from a use of ‘OptionalKeyWithDefaultCodec’                                                                                from the context: (Eq value1, Coercible input value1,
                                Coercible output value1)                                                                                bound by a pattern with constructor:                                                                                OptionalKeyWithOmittedDefaultCodec :: forall value input output.
                                                                (Eq value, Coercible input value,                                                                                Coercible output value) =>                                                                                Text
                                                                -> ValueCodec value value                                                                                -> value                                                                                -> Maybe Text
                                                                -> Codec                                                                                (Data.Aeson.KeyMap.KeyMap Aeson.Value)                                                                                input
                                                                     output,                                                                                in a \case alternative                                                                                at src/Autodocodec/OpenAPI/Schema.hs:176:7-65
             ‘input’ is a rigid type variable bound by                                                                                the type signature for:                                                                                goObject :: forall input output.
                             ObjectCodec input output                                                                                -> StateT                                                                                (HashMap Text Schema) (Declare (Definitions Schema)) [Schema]
               at src/Autodocodec/OpenAPI/Schema.hs:145:5-112                                                                                • In the first argument of ‘goObject’, namely                                                                                ‘(OptionalKeyWithDefaultCodec key vs defaultValue mDoc)’
             In the expression:                                                                                goObject (OptionalKeyWithDefaultCodec key vs defaultValue mDoc)                                                                                In a \case alternative:
                 OptionalKeyWithOmittedDefaultCodec key vs defaultValue mDoc                                                                                -> goObject (OptionalKeyWithDefaultCodec key vs defaultValue mDoc)                                                                                • Relevant bindings include
               goObject :: ObjectCodec input output                                                                                -> StateT                                                                                (HashMap Text Schema) (Declare (Definitions Schema)) [Schema]
                 (bound at src/Autodocodec/OpenAPI/Schema.hs:146:5)
           |                                                                                176 |       OptionalKeyWithOmittedDefaultCodec key vs defaultValue mDoc -> goObject (OptionalKeyWithDefaultCodec key vs defaultValue mDoc)                                                                           |

Not really strange - autodocodec-<IP_ADDRESS> seems to cause this.

@alaendle I can't reproduce this locally. These "just" compile fine on my machine.

I've successively reproduced the problem using the verify-package script. Alternatively just try to compile your package with stack using the latest nightly snapshot. Please let me know if you are still unable to reproduce this.
If I remember correctly I could build using nightly-2024-07-19, but no longer with nightly-2024-07-20 - so my suspicion that this has to do with autodocodec-<IP_ADDRESS> - since only little other packages have changed (https://www.stackage.org/diff/nightly-2024-07-19/nightly-2024-07-20).

@alaendle Aha I just figured out what happened. Fix incoming soon.

@alaendle Fixed with autodocodec-schema-<IP_ADDRESS>, autodocodec-yaml-<IP_ADDRESS>, autodocodec-swagger2-<IP_ADDRESS>, autodocodec-openapi3-<IP_ADDRESS>, and autodocodec-servant-multipart-<IP_ADDRESS>.

Many thanks @NorfairKing for your quick action!


Simplify and deduplicate README

What was wrong?
Our Readme feels a bit overloaded and it contains information that is better covered in the docs.
How was it fixed?

cleaned up Readme
moved some things into the docs
fixed some broken links
updated the introduction texts

Here is how that looks like now:

To be honest, I could be convinced to even go a step further and remove this whole goals stuff and just go with a very short intro on Py-EVM and Trinity.
Cute Animal Picture

@javimaravillas your PR #1540 triggered me to cleanup our README as well as some other parts as I think it was still very messy. Would love to hear your feedback on this.


Too much log for user

Is your feature request related to a problem? Please describe.
Logs produce too much noise (I saw thousands of records per second in one case), even when setting the log-level to WARN. This has the potential to create a large bill in Google's Logging system.
Describe the solution you'd like
Should we seperate the log into several level and make sure in some case, our kernel can only generate the least useful log?
Describe alternatives you've considered
No response
Additional context
No response

I guess we need to add some tests for log-size when there's non-trivial dataload, and define what is acceptable.
E2e tests do check log-size, but I think data load is not much, and may not test cases which lots of data.

Logs produce too much noise (I saw thousands of records per second in one case), even when setting the log-level to WARN.

Can you share what's the typical logs under the default setting and WARN level? We can see what's unintended logs. I think the points are generally correct, but not actionable. We can only handle it case by case. 🤔
Note that we can already have fine-grained control by e.g.,
RUST_LOG='risingwave_frontend::scheduler::snapshot=off' risingwave playground

to close a log like
2023-10-03T21:22:14.052352+08:00  INFO risingwave_frontend::scheduler::snapshot: unpin snapshot with RPC min_epoch=5184168463564800

I guess we need to add some tests for log-size when there's non-trivial dataload, and define what is acceptable.

Can longevity test be used for this purpose? 🤔

Can you share what's the typical logs under the default setting and WARN level? We can see what's unintended logs. I think
the points are generally correct, but not actionable. We can only handle it case by case. 🤔

This is the feedback from the user and I still try to get more details from them.
Should we make a rules from our side? We should determine which log should show in which level. Do we have a rules or RFC in our level?

I think it maybe actionable. Can check the code and just search all the logs code to see whether some of them are useless?

What about analyzing a sample of the logs from a deployment (benchmark or longevity?). e.g., calculate total count/size by log target (prefix)? That might be more efficient than reviewing all logs.

risingwave_frontend::scheduler::snapshot:: 14995 lines

it seems   risingwave_frontend::scheduler::snapshot:: 14995 lines take most of the data. Is this normal?

risingwave_frontend::scheduler::snapshot:: 14995 lines

it seems risingwave_frontend::scheduler::snapshot:: 14995 lines take most of the data. Is this normal?

To clarify this is my local log, not one from a meaningful deployment. I just included it to show an example..
BTW that line is unpin snapshot with RPC. It's normal for an idle cluster to only have this log. It seems to be useful, but also indeed a little excessive (actually, only once every 10s (UNPIN_INTERVAL_SECS),  not that many). @BugenZhao how do you think about the usage of this line?

BTW that line is unpin snapshot with RPC. It's normal for an idle cluster to only have this log.

From my perspective, in production we should never include logs that are triggered automatically and periodically, unless they're user-facing. Also applies to the DEBUG logs in hummock event handler.

actually, only once every 10s (UNPIN_INTERVAL_SECS), not that many
I think this is not much compared with what cosumer mentioned.
I saw thousands of records per second in one case
But that user have not provide his log to us.

Look at one example from longevity  (12h)
https://grafana.test.risingwave-cloud.xyz/d/liz0yRCZz1/log-search-dashboard?from=1698851271000&orgId=1&to=1698894601000&var-data_source=PE59595AED52CF917&var-namespace=reglngvty-20231101-150220&var-pod=benchmark-risingwave-compactor-c-6cc98796f5-54hz9&var-search=
(I'm not familiar with Grafana queries. Hope I'm not wrong 🥵)
compactor: 15 MB
compute-0: 124 MB
meta: 5.7 MB
frontend: 148 KB

Notice meta/compute has a peak, which is strange. Sounds like the issue met by the user.

For compute, It seems to be rate-limiter

For meta, it seems to be

cc @zwang28 any ideas about the reason and/or how to mitigate?

Look at one example from longevity (12h)

Both the example lines you listed for meta node and compute node are caused by storage back-pressure.
If the cluster is healthy, these logs won't exist. So I doubt whether they're the root cause.
Anyway I'll make these log as DEBUG, because the info can be read from Grafana instead.

If the cluster is healthy, these logs won't exist.

But should we avoid excessive logs even when the cluster is unhealthy? 🤔
If there are too many logs, it also obstruct diagnosing. Can we keep useful logs, but don't produce them repeatedly at the same time?...


v7.5.0 release without React context API breaking changes

Are you submitting a bug report or a feature request?
Feature request
What is the current behavior?
More than 20 commits with non-breaking changes were made after v7.4.2 and before v8.0.0. Many of these are bug fixes but they are only available as part of v8.x series.
What is the expected behavior?
Non-breaking changes should be made available as part of a minor or patch release. It would be wonderful to have a v7.5.0 release to capture the work that happened between the release of v7.4.2 in June, 2018, and the breaking changes introduced by #4216/#4289 in December, 2018.
Sandbox Link
n/a
What's your environment?
n/a
Other information
n/a

+1 for this. Would be nice to not have to upgrade react-redux to have those fixes.

Hm. That should be as easy as tagging the commit right before #4289 as v7.5.0.
@erikras WDYT?


[Bug] Translate Repeatables Error "Cannot use object of type stdClass as array"

Bug report
What I did
I have the field "jobs" and its a translatable field stored as fake in the extras column
$this->crud->addField([
    'name'  => 'jobs',
    'label' => 'Jobs',
    'type'  => 'repeatable',
    'new_item_label'  => 'Job Hinzufügen',
    'subfields' => [
        [
            'name'    => 'job_title',
            'type'    => 'text',
            'label'   => 'Bezeichnung',
        ]
    ],
    'fake' => true,
    'store_in' => 'extras',
    'tab' => 'Jobs',
]);

https://user-images.githubusercontent.com/37556958/171162258-ed41b199-898a-41e1-bc9f-b546d054e7a9.mov
What I expected to happen
Translation like other fields 😅
What happened
The data is stored in the database like
{
	"de": {
		"jobs": [
			{
				"job_title": "Koch"
			}
		]
	}
}

but after saving and when I want to edit the entry the error occurs
What I've already tried to fix it
Hack around the line 66 in the file app/Http/Middleware/CheckIfAdmin.php
Is it a bug in the latest version of Backpack?
Don't know. I'm using backpack since yesterday
Backpack, Laravel, PHP, DB version
When I run php artisan backpack:version the output is:
PHP VERSION:
PHP 8.1.5 (cli) (built: Apr 16 2022 00:03:52) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.5, Copyright (c) Zend Technologies
with Zend OPcache v8.1.5, Copyright (c), by Zend Technologies
LARAVEL VERSION:
v9.14.1@2ca86f96118635a79ee3389013ccab110ae14bea
BACKPACK VERSION:
5.0.19@a71715d51a0bd2827d535deb407761ee9252d044

Hi @nikolai-nikolajevic, sorry for taking so long to answer you!
Indeed there was an issue with the repeatable field, it was not ready for fake and translatable usage simultaneous.
I've open a PR to fix the issue, https://github.com/Laravel-Backpack/PRO/pull/76.


Changing ssl-default-* settings with env params?

Wouldn't it be nice to configure ssl-default-* settings via env params?
Currently we are using our own haproxy.cfg to set a different cipher.

It's available in the release 1.316. Can you please try it out and let me know if it works as expected.


⚠ Bofrost.lu has degraded performance

In 0dc72ed, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 933 ms

Resolved: Bofrost.lu performance has improved in dff6767 after 9 minutes.


Hedoku No Longer Available

Starting November 28, 2022, Heroku stopped providing a free tier to its users. If I am not mistaken, the current price is $5 per month. Is there any other way to generate the token without Heroku? Can generating an access token with the Instagram Basic Display API be used as an alternative?

You can use https://www.instant-tokens.com to do this, it isn't free but is considerably cheaper than Heroku. There is a guide on setting this up here https://www.instant-tokens.com/pages/guides/post/adding-instagram-feed-to-your-website
Full disclosure: I built Instant Tokens


Release 0.32.0

Any chance you could cut a new release so that rake tasks work again? Thanks!

0.32.0 has now been released.


Start a Wiki page about what we want as features (detailled)

This post is used to discuss about what features we want in Langscaper and how it will be presented. This may impact the architecture #10
The wiki page could be something like that  :
UI
interfaces
how will be organized the views ?  image of mock-up idea, etc...
is that possible to move and dock the views ?
theme system
what is planned for managing themes ?
File system

save/load language (with which extension ? ex : .ls, .lang, .conlang ?)
import/export language (to which format ?)
import/export phonological system ( = human anatomy possible sounds, alien anatomy, etc..)

Phonology
What features here ?
How will be the views ? What can we made ?
Is there a different view for Inventory, Phonotactic , Pronunciation, etc... or just a long scrolling page ?
Grammar
What feature in this section ? I think about :
Syntax tree
Typology ( like VOS order, define if possession are alienable, etc... )
Part Of Speech and Lexical Classes
Inflection system (rules, congugation/declension tables, etc...)
Documentation (user's grammar articles and docs)
Lexicon
Ideas :
Dictionnary
Phrasebooks
Translations (collection of user's text)
Writing System
Ideas :
Graphem font system
Alphabetical order
Wiki
Ideas :
A home page with :

ID card of the language (name, speaker's species, place where it's spoke, status)
Genealogy tree with other languages
Articles (user's custom documentation)

Evolution tools
I don't know what can of tool we wanted

Starting with phonology, i believe we could begin with:

Consonant and vowel selection
Phonotactics
Stress rules
Intonation (This one could be just a text box, as conlangs are not often spoken by anyone, but is good to have a place to put intonation if needed)
Allophony

I dont think we should introduce tone features yet, i think its very hard, at least for me, to think and explain how to translate the feature into a tool.


Regression with druid 28 - round generates java.lang.RuntimeException when applied on sys tables

Please provide a detailed title (e.g. "Broker crashes when using TopN query with Bound filter" instead of just "Broker crashes").
Affected Version
Working on druid 27; but not working on druid 28
Description
I do not think that cluster size or configuration has any impact.
I have some basic query to check the size of druid segments from the druid console:
SELECT datasource, avg(size)/1024/1024 as size_mb FROM sys.segments group by datasource

With druid 27.0.0, the "size_mb" was automatically converted to a bigint.
With druid 28.0.0, the "size_mb" is no more converted and is returned as a double. Fair enough.
But when I tried to apply some rounding on it, it does not work:
round(avg(size)/1024/1024)
round(cast(avg(size)/1024/1024 as DOUBLE))
round(cast(avg(3000)/1024/1024 as DOUBLE),1)

In any case, in the druid console, I get the following error:
Error: RUNTIME_FAILURE (OPERATOR)
cannot translate call ROUND($t7)
java.lang.RuntimeException

And I also have this warning in the logs of the broker (but no stacktrace):
2023-12-12T12:58:11,484 WARN [sql[bb34e9cd-7422-4c38-93af-2ee86d850e50]] org.apache.druid.sql.http.SqlResource - Exception while processing sqlQueryId[bb34e9cd-7422-4c38-93af-2ee86d850e50] (org.apache.druid.error.DruidException: cannot translate call ROUND($t18))

Note: I do NOT get any issue  when querying directly on a value (for instance round(0.4134190559387207 , 1)) or when querying on a datasource (it only happens on sys tables.

I also tried the above example:
SELECT datasource, round(avg(size)/1024/1024) as size_mb FROM sys.segments group by datasource
Druid 27: works
Druid 28: Error: RUNTIME_FAILURE (OPERATOR), cannot translate call ROUND($t7)
Maybe there is a 'connection' with the issue I created:
https://github.com/apache/druid/issues/15562

Issue fixed with #15562 .
Thanks for reporting it.
The fix would be part of druid 29 release.

Observed the same issue with SUBSTRING in Druid 29.0.1, was there ever a fix for this?
SELECT
SUBSTRING("segment_id",5) AS "segment_s", "num_rows"
FROM "sys"."segments" WHERE "datasource"='adsb-json' LIMIT 7

Error: RUNTIME_FAILURE (OPERATOR)

cannot translate call SUBSTRING($t0, $t19)

java.lang.RuntimeException


feat(curriculum): Add solution to combining an array into an string

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] All the files I changed are in the same world language (for example: only English changes, or only Chinese changes, etc.)
[x] My changes do not use shortened URLs or affiliate links.

Closes #XXXXX

Added to PR #37161 instead


PrometheusMetricsTrackerFactory issue with multiple pools

Environment
HikariCP version: 2.5.1
JDK version     : 1.8.0_111
Database        : OracleDB
Driver version  : 12.0.2
If i create two HikariCP pools in one JVM and set the PrometheusMetricsTrackerFactory  it causes the below exception because the collector name gets registered twice.  The collectors should be static and should record the pool label (dimension) only on observation of a metric.
Caused by: java.lang.IllegalArgumentException: Collector already registered that provides name: hikaricp_active_connections

@ankurbhakta The Prometheus support was contributed by @tokuhirom .  I seem to recall that there was some reason he did not want to qualify the metric with the pool name, as we do with DropWizard metrics.  May he can comment?

@tokuhirom is correct. We should not qualify the metric name with the pool name.The pool name is a dimension in time series data perspective that can be queried upon. I created a pull request with minor tweaks to fix this issue.
https://github.com/brettwooldridge/HikariCP/pull/851

I believe this was fixed by https://github.com/brettwooldridge/HikariCP/pull/890 (released in 2.6.2) and can be closed.

I don't think this was resolved. I am running 3.3.1 and when trying to create multiple pools, there is an exception:
storefront java.lang.IllegalArgumentException: Collector already registered that provides name: hikaricp_connection_timeout_total
 	at io.prometheus.client.CollectorRegistry.register(CollectorRegistry.java:54)
 	at io.prometheus.client.Collector.register(Collector.java:139)
 	at com.zaxxer.hikari.metrics.prometheus.PrometheusMetricsTracker.registerMetrics(PrometheusMetricsTracker.java:71)
 	at com.zaxxer.hikari.metrics.prometheus.PrometheusMetricsTracker.<init>(PrometheusMetricsTracker.java:63)
 	at com.zaxxer.hikari.metrics.prometheus.PrometheusMetricsTrackerFactory.create(PrometheusMetricsTrackerFactory.java:55)
 	at com.zaxxer.hikari.pool.HikariPool.setMetricsTrackerFactory(HikariPool.java:308)
 	at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:118)
 	at com.zaxxer.hikari.HikariDataSource.<init>(HikariDataSource.java:81)

This line is problematic: https://github.com/brettwooldridge/HikariCP/blob/86cabf08623a8f9c9ab697a95a277690496b6fae/src/main/java/com/zaxxer/hikari/metrics/prometheus/PrometheusMetricsTracker.java#L63

This hasn't been working for a while, try switching to micrometer using MicrometerMetricsTracker, which can delegate to prometheus, datadog, netflix atlas etc. We have been using that in production for a while.


Understand fetcher & mapper associations

Added new section to the "Analysis of Existing Infrastructure" wiki page: https://github.com/ucldc/rikolti/wiki/Analysis-of-Existing-Infrastructure#relationship-of-fetchers-to-mappers

@amywieliczka @christinklez @aturner I updated the script to use Amy's published filter, and now the output makes more sense.

Adrian and I reviewed this, and think the list looks great! Thank you @barbarahui !


Url resources initialization from cache

:construction:

Codecov Report

Merging #13750 (f437f49) into main (8831138) will increase coverage by 4.73%.
The diff coverage is 46.03%.

@@            Coverage Diff             @@
##             main   #13750      +/-   ##
==========================================
+ Coverage   38.79%   43.53%   +4.73%
==========================================
  Files        1086      836     -250
  Lines       73804    65534    -8270
  Branches     5027     4685     -342
==========================================
- Hits        28635    28531     -104
+ Misses      45126    36946    -8180
- Partials       43       57      +14

Impacted Files
Coverage Δ

core/boot.js
23.60% <0.00%> (ø)

core/server/services/url/UrlService.js
51.35% <35.29%> (-4.89%)
:arrow_down:

core/server/services/url/Resources.js
41.20% <100.00%> (+0.73%)
:arrow_up:

core/server/services/url/index.js
100.00% <100.00%> (ø)

core/server/data/db/connection.js
62.26% <0.00%> (-32.08%)
:arrow_down:

core/shared/config/loader.js
89.47% <0.00%> (-7.90%)
:arrow_down:

core/frontend/services/helpers/index.js
94.44% <0.00%> (-5.56%)
:arrow_down:

core/server/services/themes/loader.js
95.45% <0.00%> (-4.55%)
:arrow_down:

core/frontend/services/routing/registry.js
70.24% <0.00%> (-4.14%)
:arrow_down:

core/server/services/slack.js
94.76% <0.00%> (-4.07%)
:arrow_down:

... and 284 more

Continue to review full report at Codecov.

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


update build configuration for 0.6+

Signed-off-by: Bo-Yi Wu<EMAIL_ADDRESS>

Should this be the new generalized format? Has @bradrydzewski said anything to that?

See the changes: https://github.com/drone-plugins/drone-s3/commit/3351e6323bc87699bff8cc309c57e7bef779ceb7

Commented on a specific package that have been needed: https://github.com/drone-plugins/drone-s3/commit/3351e6323bc87699bff8cc309c57e7bef779ceb7#commitcomment-23841564

@tboerger Good point. waiting for @bradrydzewski response

Maybe @bradrydzewski can create a drone/scratch repo, there we can add the alpine ca-certificates.crt and mime.types and use it as base image for the plugins. That's even better because it's in the control of Drone and can get updated by us without issues. Looks like the https://github.com/CenturyLinkLabs/ca-certs-base-image image is already 2 years old, so the ca-certificates.crt can already be changed a lot.

agree with @bradrydzewski maybe we can create base image naming as plugin/base first or using multiple stage build. Which one do you prefer? @tboerger
FROM plugin/base
ADD release/linux/amd64/drone-s3-cache /bin/
ENTRYPOINT ["/bin/drone-s3-cache"]

@bradrydzewski @tboerger I already add mime types file.

I would personally prefer a base image to reduce the noise on all the plugin builds, but in the end the decision is up to @bradrydzewski. Maybe add images as plugins/base:scratch and plugins/base:alpine? Quite simple base images of course, but only a single place to build them instead of multi stage builds over and over again :)

Looks good. I think can probably omit mime.types from this plugin since it is uploading tarballs for internal use only.

@bradrydzewski can you add docker_username and docker_password on drone-plugins org in drone?
https://beta.drone.io/drone-plugins/drone-hg/14

@bradrydzewski can you add docker_username and docker_password on drone-plugins org in drone?
https://beta.drone.io/drone-plugins/drone-hg/14

Not really related to this issue but I have added the secrets.

@bradrydzewski I removed the mime.types file.

What about a windows build?

Windows should also work without issues

Looks like you have applied most of the stuff I have also introduced. So I'm fine with that if we found a consensus

@tboerger Yes,

@tboerger Great. Thank you.


APIGOV-23982 - Register agent resource on agent initialization

Updates to create agent resource based on the agent type if resource does not exists
Derive the agent name based on the environment name suffixed with short name for agent type
Changes to update x-agent-detail sub resource on Environment resource to indicate the specific agent type is enabled in the environment

Looks good... do we need any migration path?

No migration needed, the agent initialization updates the environment resource if the x-agent-details sub resource is not present or the agent type enabled property is not present. For agent resource creation, the initialization creates the agent resource if agent resources is not already present.


Update an output to use env var not hard coded value

Signed-off-by: Alistair Hey<EMAIL_ADDRESS>Description
The example output when using --remote-tcp to create an inlets-pro exit node was setting and env var and not using it.
Fixes #24
How Has This Been Tested?

Command:
  export TCP_PORTS="8000"
  export LICENSE=""
  inlets-pro client --connect "wss://<IP_ADDRESS>:8123/connect" \
        --token "my_secret_token" \
        --license "$LICENSE" \
        --tcp-ports $TCP_PORTS
To Delete:
          inletsctl delete --provider digitalocean --id "175013350"

then i tested this by setting up the client and then SSHing to the local RPi through the exit node
The authenticity of host '[<IP_ADDRESS>]:2222 ([<IP_ADDRESS>]:2222)' can't be established.
ECDSA key fingerprint is SHA256:Oc4wNrUObnzGqjVjpXLPd48k0R8EuFi1Bu4ycXXjHCc.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[<IP_ADDRESS>]:2222' (ECDSA) to the list of known hosts.
Linux raspberrypi 4.19.75-v7+ #1270 SMP Tue Sep 24 18:45:11 BST 2019 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Jan 10 08:33:52 2020 from <IP_ADDRESS>

I then deleted the node using the newly added output:
heyal@heyal-xps:~/go/src/github.com/inlets/inletsctl$ inletsctl delete --provider digitalocean --id "175013350" -f ~/do-token
Using provider: digitalocean
Deleting host: 175013350 from digitalocean

How are existing users impacted? What migration steps/scripts do we need?
Added extra clarification to output. no impact to existing versions.
Checklist:
I have:

[ ] updated the documentation and/or roadmap (if required)
[x] read the CONTRIBUTION guide
[x] signed-off my commits with git commit -s
[x] added unit tests

What port did you use for your RPi?

What port did you use for your RPi?

2222

Same as me, so that it doesn't conflict with the exit node.. just edited sshd_config and added?

Same as me, so that it doesn't conflict with the exit node.. just edited sshd_config and added?

yeh. made sure i disabled password auth too :closed_lock_with_key:

That's what I like to hear 💪  Yesterday I didn't bother, for a short-term session, but did update the default password first 🤓  https://blog.alexellis.io/hardened-raspberry-pi-nas/


fix pubkey auth

fix permissions on authorized_keys, exclude some old versions for pubkey auth, due to missing support for encryption alg
This should fix #70
All unit tests with pubkey Auth fail on my machine, strange that the build on github succeeds

May it is easier to remove support for the older image versions

Thanks for the fix. I will release a new version.


The code sample (Quick Start) does not work, even after porting to .NET standard library

I did the quickstart located here https://developer.microsoft.com/en-us/graph/quick-start and it does not work.
It generates a PCL app so I converted it to .NET standard and then had to change code because what gets created uses deprecated functions in the SignOut method of AuthenticationHelper.cs.
When I run on UWP I get an error after providing the account.

It seems that no one is keeping up with and or testing these code samples.
Has Microsoft Graph been abandoned or deprecated ?
Can I get a working example that runs with Xamarin.Forms ?

Anyone ???

We're archiving this sample and redirecting folks to https://github.com/microsoftgraph/msgraph-training-xamarin (or the corresponding walkthrough at https://docs.microsoft.com/graph/tutorials/xamarin.