./boringproxy-linux-arm failed to create client

Hi, I seem to have a talent for finding problems. I have a tunnel which appears to be correctly specified in the web interface/tunnels:
camera.thewensleyhouse.xyz:41389 -> thecamera -> <IP_ADDRESS>:5000
But I cannot start the client on the remote machine:
pi@Cedd:~ $ ./boringproxy-linux-arm client -server camera.thewensleyhouse.xyz -user admin -token zBTuQ9bjV9lfVtjZVSVIamiiIlkQnWUw -client-name thecamera
Failed to create client. Ensure the server is running. URL: https://camera.thewensleyhouse.xyz/api/users/admin/clients/thecamera
The server is in fact running:
pi@raspberrypi:~ $ ./boringproxy_arm server
2021/02/10 16:32:37 Starting up
2021/02/10 16:32:38 Enter Admin Domain:
camera.thewensleyhouse.xyz
2021/02/10 16:33:04 Successfully acquired admin certificate
2021-02-10T16:33:19Z <IP_ADDRESS> GET camera.thewensleyhouse.xyz /
2021-02-10T16:33:20Z <IP_ADDRESS> GET camera.thewensleyhouse.xyz /logo.png
2021-02-10T16:38:16Z <IP_ADDRESS> GET camera.thewensleyhouse.xyz /login/
2021-02-10T16:38:16Z <IP_ADDRESS> GET camera.thewensleyhouse.xyz /logo.png
2021-02-10T16:38:20Z <IP_ADDRESS> GET camera.thewensleyhouse.xyz /
2021-02-10T16:38:20Z <IP_ADDRESS> GET camera.thewensleyhouse.xyz /logo.png
2021-02-10T16:41:58Z <IP_ADDRESS> GET camera.thewensleyhouse.xyz /logo.png
2021-02-10T16:43:03Z <IP_ADDRESS> GET camera.thewensleyhouse.xyz /logo.png
(The reason there are so many GETs is because I had difficulty logging in to the web interface unless I use /login?access_token=... with the address - I can't get it to prompt me for a token, so I needed several attempts before getting it right - but that's a different issue)

Hi, I seem to have a talent for finding problems

That's a useful talent!
I'll think about this and get back to you. In the mean time I just wanted to mention a couple things:

You probably don't want to post your actual server address publicly here, and definitely no any real tokens. Not sure if they ones you shared are real or not but just making sure.
For the login issues, I agree it's a bit clunky. I ran into some issues with redirects early on and just gave up, but I need to revisit it. For now, what you probably want is to visit /#/tunnels on the admin domain.

Thanks, @anderspitman. Yes, that was a bit of a slip (posting something like an actual address/token). My intention once I've got everything working and understood, is to wipe the machines and start again from scratch for deployment - but I take your point.
I'll be investigating my problem further today and will let you know if I find anything significant.

Hi @anderspitman, I can't get a handle on this problem at all. I deleted the executables on server and client, and the .json db file on the executable, then downloaded . -linux-arm version again onto both machines so I'm sure they have the same version. I've checked the setcap on the server. The server works fine and I can access the web interface. But I cannot get the client to run.
This is particularly annoying because clearly at one time it was, in fact, running, otherwise I would not have the tunnel, as shown in my original post (of course, I've lost that now that I have reinstated the executables). The only way I would have made that tunnel was from the client as described in your video. I'll go away and smoke something while I think about it ...

@Zygodon I think I might know the problem. Your admin-domain and tunnel domain need to be different. ie when you run the client, -server needs to be a different value from the tunnel domain.
The reason is because the server uses the domains to know whether to handle the request itself (such as for the UI) or proxy it to a tunnel.

There's obviously room for improved documentation here.

The sub-domains are different. Like in your demo (form memory) your apex (?) domain is brng.pro; the server is bpdemo.brng.prp and the client is etherpad.brng.pro. In my case I have the apex domain as shown above with subdomain camera for the server; then I was using thecamera as the client name (that's too confusing, I use "my_client" now but the pronciple is the same).
Is that not OK?

Apologies for the typos.

When you start the client you're using -server camera.thewensleyhouse.xyz. I think you need -server thewensleyhouse.xyz, or whatever your admin-domain is. They tunnel domain and -server can't be the same.

I must be misunderstanding something. I deleted boringproxy_db.json to persuade boringproxy that it was starting afresh. I started boringproxy server and gave it domain name camera.thewensleyhouse.xyz. I was able to open the web interface at https://camera.thewensleyhouse.xyz. with the new token of course.
Over to the client machine, ./boringproxy client -server thewensleyhouse.xyz -token the new token etc.
Still get "Failed to create client".

What is the value of admin-domain when you start the server?

camera.thewensleyhouse.xyz
(I've tried using just thewensleyhouse.xyz on first starting the server, but then the system knows nothing about a camera sub domain and I don't know where to give it that information. And I still can't start the client!)

Both server and client are inside my home router (NAT). I've port forwarded the server's port 80 to the router, and in Namecheap I've got the records pointed at the public address of the router. But - I guess, WITHIN my local network, the potential client doesn't know about that ...?

camera.thewensleyhouse.xyz
(I've tried using just thewensleyhouse.xyz on first starting the server, but then the system knows nothing about a camera sub domain and I don't know where to give it that information. And I still can't start the client!)

Yeah I'm pretty sure this is your problem. They need to be different. What do you mean by "the system"? Are you referring to boringproxy, or your DNS setup, or something else? The way that you tell boringproxy about the subdomain is by using camera.thewensleyhouse.xyz when you create the tunnel in the web UI.

Both server and client are inside my home router (NAT). I've port forwarded the server's ports 80 and 443 to the router, and in Namecheap I've got the records pointed at the public address of the router. But - I guess, WITHIN my local network, the potential client doesn't know about that ...?

That should work fine. But since you're hosting directly from home, have you considered using a traditional reverse proxy like Caddy (or nginx etc) instead? boringproxy is specifically designed for running on a public server like a VPS, since that's when it gives you the most advantages.

ps you don't necessarily have to use thewensleyhouse.xyz for the admin domain. You can also use something like admin.thewensleyhouse.xyz. You just can't use the same domain for any of your tunnels.

Aha, that could be helpful, thank you; I'll try again tomorrow. Boringproxy is best for me, I think, because ultimately the client will be at a truly remote location, communicating on the cell phone network. The set up at the moment is just for development where I have immediate access to both machines. And anyway it's cheaper to get it running on the WiFi, I don't want to use more data on my SIM than necessary.

That makes sense. Another feature I plan added eventually is control over how often the client polls the server for tunnel updates. Currently it's quite chatty (every 2 seconds), which will needlessly use up data in your use case. I think often tunnels don't change much, and you could get away with minutes or even hours between polling, or even just checking at startup.

I'll keep in touch about that once I'm in a deployment situation. Meanwhile I'm still hacking away at my problem - only now I find server cannot get a certificate for admin.thewensleyhouse.xyz. Looks like we're back to the problem before last! I've deleted boringproxy_db.json and made a new, empty authorized_keys file in /.ssh.
Is deleting the db.json file an adequate way of getting back to square one? Else, how can I get certificates for thewensleyhouse.xyz and camera.etc, but not admin.etc?
So I'm going to leave it for now!
Cheers, @anderspitman, and thanks for your help

You can also try deleting $HOME/.local/share/certmagic, but I'd be surprised if that changes anything. certmagic has been solid about keep its state in good shape.
Are the permissions on authorized_keys 600?
You're sure your DNS is setup up with a proper wildcard, ie A record *.thewensleyhouse.xyz -> your router IP?

Hi @anderspitman. Today I've made progress and I can get the client running. Thank you for your suggestion about having an admin subdomain, that was a great help in clarifying my understanding and I think was the crucial step in solving the immediate problem. For anybody else who may be experiencing similar difficulties, I found your advice to delete $HOME/.local/share/certmagic useful in getting me completely reset to a clean start, as well as creating a new, empty authorized_tokens file with the appropriate permissions (600).
So, I consider this issue resolved, if you would like to close it. Unfortunately, though, I've still not quite jumped through all the hoops; I'll start a new issue to deal with my next problem.
As ever, thanks for your help and patience.

Glad you got it working @Zygodon. I don't quite understand everything going on with the other issue but I'll try to take a look at it again tomorrow.


Add workflows to verify if examples are valid

We have many examples, and these allow users to understand easily how to perform TrainingJobs.
However, we don't have any verifications if the examples are valid. So, I would propose that we add CI workflows to verify that examples are working.
Katib workflows would be good examples to implement in the training-operator: https://github.com/kubeflow/katib/blob/master/.github/workflows/e2e-test-pytorch-mnist.yaml
/good-first-issue

I'd like to work on the GitHub Action for this training operator examples issue. It matches my difficulty level.
Any guidance you can provide would be greatly appreciated.
/assign

implementing the GitHub Action for verifying training operator examples, I wanted to clarify the approach. Should I create separate actions for each framework job (e.g., TensorFlow, PyTorch, XGBoost, etc) like the Katib E2E test actions, or is there a different recommendation?
Your guidance would be much appreciated.

@tenzen-y Are adding e2e tests in workflow necessary for verifying Training Operator examples like in Katib? Can you provide some additional information to this. it helps me to solve this issue

@tenzen-y Are adding e2e tests in workflow necessary for verifying Training Operator examples like in Katib? Can you provide some additional information to this. it helps me to solve this issue

We need to implement the following steps in the script:

Build example and operator images
Start KinD cluster
Load built images into the cluster
Set up the TrainingOperator
Create a Job with built images
Verify if a created Job succeeded.

/remove lifecycle/stale


Fixed #46

This fixes #46 by changing from .issues to .pullRequests. The app is not
granted READ to the issues domain, and thus was breaking this.

@nesl247 I appreciate your help but I also have implemented to fix and refactor. #64. I closed it but your amazing help will be useful.


Use auto labeler to label the issues and PR with Hacktoberfest

Use this: https://github.com/marketplace/actions/labeler

hey @AnirudhPanda  can this be closed if the requirements are fulfilled or do you want something else too?

I don't want to merge the main with v1.0.0 as of now!
Should we create the same thing on v1.0.0 branch?

I can do that , i should branch off from v1.1.0 am i correct?

I can do that , i should branch off from v1.1.0 am i correct? also do you want to include your auto assign bot changes and other stuff which you included in main branch yesterday?

No only the labeler!

please review - https://github.com/Opentek-Org/bookquotes/pull/51


Renaming skills

Currently, the skill names are ambiguous. Renaming some of the skills could be good.
An extensive list of skills can be found here
What are your thoughts @agiani99 @jburel?

Done with discussion with philip


Answer options based on the first item in a list

What is the context of this PR?
This PR allows placeholders to resolve answer values based on an answer of the first item in a list.
The list_item_selector field has been expanded to support retrieving the first item from a given list e.g.
"list_item_selector": {
   "source": "list",
   "id": "people",
   "id_selector": "first"
}

How to review
You can use the test_answer_based_on_first_item_in_list schema to test this change.
Check all tests pass.

 [K] Feature to allow placeholders to resolve the first item in a list (M)

.python-version needs bumping to  3.8.3


Clarity -- required

It's a little unclear but It looks like the bash script is building Idris2. I have previously installed Idris2 from Homebrew. Should it be uninstalled?
Main issue  --
A trust issue
Not necessarily malicious, I always feel uncomfortable allowing a shell script to create things without have some idea of what's going on.  So please let me know if I have the following correct.  And more importantly ... why should I trust this script do the things, I am unfamiliar with.
The shell script

-# Verify that the necessary programs( items) are installed ... stet
...

-# Install package collection .. stet   just making some directories and copying the cloned files around
...

-# Bootstrap the Idris compiler ... Hmmm  DO I understand this right?  The package manager needs to building idris2
a) git clone https://github.com/idris-lang/Idris2.git "$PACK_DIR/clones/Idris2"   <-- THE IDRIS2 SOURCE?
...
a series of makes  ... there is a lot of trust going on, without reviewing the IDRIS makefile ( I do let homebrew compile code)

-# Install filepath  ... what is ?filepath  Is this part of the IDRIS external curated libraries?
--- Okay I guess  --- idris2-filepath: Unix style file paths in Idris2

-# Install toml-idr ---   Okay what is this, and who is cuddlefishie? :  https://toml.io/en/   and is toml  -- IS it an IDRIS parser ??
--- Okay I see that  -- TOML is widely supported  cuddlefish is

-# Install pack  --

-# # Initialize pack.toml

-# cleanup

It's a little unclear but It looks like the bash script is building Idris2. I have previously installed Idris2 from Homebrew. Should it be uninstalled?

It's up to you. Idris does not have to be installed for pack to work since pack manages Idris installation itself, but it uses separate installation paths, so they can be installed in both ways simultaneously. But there is no need for separate Idris installation once you've installed pack.

why should I trust this script do the things, I am unfamiliar with

Looks like it means you have to be familiar with every piece of software running on your machine. It is hard to know such many things, nowadays, I think ;-)

3. Hmmm  DO I understand this right?  The package manager needs to building idris2

Yes, it's right, pack itself it written on Idris, and installation of pack does not require Idris to be installed, so it does it itself.

3. a) git clone https://github.com/idris-lang/Idris2.git "$PACK_DIR/clones/Idris2"   <-- THE IDRIS2 SOURCE?

Right, pack manages sources of what it installs, including sources of the compiler

-# Install filepath  ... what is ?filepath  Is this part of the IDRIS external curated libraries?
-# Install toml-idr ---   Okay what is this, and who is cuddlefishie? :  https://toml.io/en/   and is toml  -- IS it an IDRIS parser

These are external libraries that are used by pack itself. Since pack is not built yet, these particular libraries are installed manually by the script. Once pack is installed, it would manage these libraries from the curated package list.
toml-idr is a parser of the TOML file format which is used for configuration files of pack.

I tried to answer to all small questions in your text, but I couldn't find a structure in your message, for instance, why did you list items 6, 7 and 8 if you don't have questions to them?

Thanks @buzden for taking the time to answer this.

Firstly thanks for taking the time to answer my questions. I have installed idris2-pack on my personal computer so I can evaluate the capabilities of idris2 and the idris2 development environment (idris2-pack, toml, etc. ) further.
Secondly, a major concern is software vulnerabilities, especially with many of the industries that I support. I wanted to try and assess how easy it is  to determine the vulnerabilities of  idris2-pack to exploits and threats. Especially when the installation procedure is ... execute this bash script.  The current installation procedure for idris2-pack would not be acceptable in  many commercial environments. There is no easy way to determine its vulnerabilities.
Thirdly, the order I asked my questions was in the same order that the bash script executes. I was trying to assess the script, as I was writing the questions. Yes, it was not always clear what was going on without digging further. Which I did not want to do at the time.
Fourthly, it is never a good form to make a personal assessment  about another.  When evaluating software, yes, industries "have to be familiar with every piece of software running on [their] machine." They need to know how vulnerable the software is to exploits and attacks, internally and externally. In essence, can one prove the software being loaded onto a system only does what it suppose to do. Which is one of he benefits of idris.
Finally, one final question.  Is the idris-pack package manager coupled to the idris2 language? It appears that you indicate it is. This implies that the indris-pack needs to be rebuilt every time idris is rebuilt. -- To be clear, I am not implying this is a bad thing. It may be necessary, if the intent for "curated code: is to ensure that it performs as expected and not open to exploits.
Thank you -- again

The current installation procedure for idris2-pack would not be acceptable in many commercial environments. There is no easy way to determine its vulnerabilities.

Do you suggest any ways that are more acceptable from your perspective? Say, you can have an installation of pack using docker image, which generally is definitely accepted widely in commercial environments.

Fourthly, it is never a good form to make a personal assessment about another

I didn't make any assessment of your person. But your original statements and questions were formulated very personally (" I always feel uncomfortable ...", "why should I trust this script do the things, I am unfamiliar with"), so why shouldn't I talk about your personal preferences, then? If your original statement was "pack's installation script does but conform this international standard of safe installation procedures", there would be no place for anything personal at all.

This implies that the indris-pack needs to be rebuilt every time idris is rebuilt.

It does not. pack is a standalone executable and once it's compiled on your machine, it can manage any version of the Idris2 compiler. But once you ask pack to update itself using pack update, it will you the current idris2 version to build itself.


Added 'ignoreExts' argument for node implementation

So that one could ignore .js, .css file changes to only track .gz files.
server = require('livereload').createServer( {
    exts: [ 'gz' ],
    ignoreExts: [ 'js', 'css' ],
    https: { key: fs.readFileSync( process.env.SSLKEY ), cert: fs.readFileSync( process.env.SSLCERT ) },
    originalPath: `https://${process.env.DOMAIN}.com`
} )

What do you think?  I am happy to work on this with you further.

Please submit a new pull request written in CoffeeScript, and if possible, provide a test.

I don't know CoffeeScript, and prefer to use nodejs.  Would you accept only a test?
It is basically a one-liner, would you be willing to write the CoffeeScript?

When I inherited the project, it was written in CoffeeScript, so I used CoffeeScript. Your diff shows more than one line changed. I'm happy to merge in a CoffeeScript commit.

Geh, then I guess I'll have to fork.  This is unfortunate.
On Tue, Aug 9, 2016 at 3:55 PM, Brian Hogan<EMAIL_ADDRESS>wrote:

When I inherited the project, it was written in CoffeeScript, so I used
CoffeeScript. Your diff shows more than one line changed. I'm happy to
merge in a CoffeeScript commit.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/napcs/node-livereload/pull/73#issuecomment-238671258,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABk4qrvykUrzgKA4mkG--X1e4TyRxWPDks5qeNsYgaJpZM4Jc3a6
.

--
Chris Baron

@cbaron rather than forking and thus having to maintain your own unofficial version, wouldn't that time be better spent using js2coffee and making the patch? :) Then we all benefit.  http://js2.coffee/

If you're going to maintain this package, then you'll have to meet me
halfway.  I have written a few lines of code that add an extra parameter.
On Wed, Aug 10, 2016 at 1:42 AM, Brian Hogan<EMAIL_ADDRESS>wrote:

@cbaron https://github.com/cbaron rather than forking and thus having
to maintain your own unofficial version, wouldn't that time be better spent
using js2coffee and making the patch? :) Then we all benefit.
http://js2.coffee/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/napcs/node-livereload/pull/73#issuecomment-238771139,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABk4qtSW3zoEXlpgY_es0OuE012Gjvs9ks5qeWTagaJpZM4Jc3a6
.

--
Chris Baron


Remove auto-generated content from repo

The files main.css and main.css.map are auto-generated. Make sure, removing them does not break anything and remove them.

[x] Include the steps to generate them in Dockerfile,
[ ] Update README.md.
[ ] Possibly automate steps to generate them in a pythony way. (Some scripts in package.json might also do the job,)
[ ] git-ignore them

The css fles are already being generated during the "build frontend" stage of the dockerfile.

Maybe there is a way to tell the python manage.py runserver command to execute the compile step at startup when using the local configuration..?


Suggestion for rotation with immediate behavior change

Context
Currently RISV-V vector crypto extensions defines two rotation instructions vror and vrol , SEW-wide right and left element-wise rotations. Each admits 3 variants .vv , .vx , .vi with the straighfoward specification.
https://github.com/riscv/riscv-crypto/blob/master/doc/vector/insns/vrol.adoc
https://github.com/riscv/riscv-crypto/blob/master/doc/vector/insns/vror.adoc
Issue:
The .vi  uses the default 5-bit immediate as an unsigned rotation amount.
the imm=0 value is useless since it corresponds to the identity
for SEW = 64 bits,  rotation by 32 bits (left or right) is inaccessible.
It was suggested to shift the immediate by 1 such that accessible rotation becomes [1, 32] but this implies incrementing the rotation amount from the default value.
Suggestion:
What if we remove vrol.vi (a)  and define a vector right rotation by SEW/2 + imm instead, let's call it vroro.vi   (right rotation with offset). The offset by SEW / 2 is easy to perform (this rotation amount wraps around, at most a one bit addition is required for any SEW) and it becomes possible to cover rotation by 32 for SEW=64.
vrol.vi vd, vs2, imm  can be implemented by vroro.vi vd, vs2, SEW / 2 - imm[log2(SEW)-1:0]  when imm[log2(SEW)-1:0] <= SEW/2  or by  vror.vi vd, vs2, SEW - imm[log2(SEW)-1:0]  when imm[log2(SEW)-1:0] > SEW/2:
For example

vrol.vi vd, vs2, 5 for SEW=16 is implemented by vroro.vi vd, vs2, 3 (which is a right rotation by 11 bits)
vrol.vi vd, vs2, 9 for SEW=16 is implemented by vror.vi vd, vs2, 7 (which is a right rotation by 7 bits)

Drawbacks

non-uniform use of op encoding for vrol / vror
may need to mux between vs1 and vs1 <<< (SEW / 2)  before applying the actual rotation

(a) (this was suggested by @aswaterman  rather than removing vror.vi since scalar bitmanip only has rori)

I think the idea is good but it will increase the "decoding effort" when reading/writing the assembly code.
vrol.vi vd, vs2, 5 for SEW=16 is
equal to vror.vi vd, vs2, 11 and is
equal to vroro.vi vd, vs2, 3 with context SEW=16
The rotate length of  vroro.vi vd, vs2, 3 will depend on SEW, and the original vror.vi/vrol.vi do not.

This is an interesting idea and would close gap of not being able to rotate a 64-bit value by 32.
A simpler alternative that could achieve the same end would be to remove rol.vi and define ror.vi to use one of the funct6 bits as uimm[5].
If we kept the current encodings we could use instruction[27] as uimm[5]. Alternatively, we could also change the proposed encoding for ror.vi tp be funct6[5:0]=01010x where x would be used as uimm[5].

Instead of ofsetting, the  imm=0 can be special cased to be 32 or SEW/2. Though attempt to do it in vsetivli failed for some reason.
Also, immediate rotation by 32 can be done by vrev32

I think Ken's and Nicolas' suggestions result in identical hardware and are only descriptively different: Nicolas describes two instructions distinguished by a single funct6 bit, and Ken describes a single instruction with a 6-bit immediate, of which bit 5 happens to be in the funct6 field.  Ken's proposal is cleaner for assembly programmers.
I also thought about @jnk0le's approach, but (assuming under that regime we'd keep both vrol.vi and vror.vi) it doesn't save any opcode space versus the other proposals, and seems to me to be less clean than the others.

Discussion continues on the mail group: https://lists.riscv.org/g/tech-crypto-ext/topic/removal_of_vrol_vi_and/94897241

The specification has been updated by removing vrol.vi and modifying vror.vi to have a 6 bit unsigned immediate composed from instruction encoding bits 26,19:15


MJPEG video encoding possibility along side h264, h265

While @themarpe and @Luxonis-Steven were chatting about the OpenDataCam MJPEG streaming (see depthai-experiment here, @themarpe got an idea about supporting MJPEG directly as an output from DepthAI/megaAI:
Feature:
We should have a MJPEG video encoding possibility along side h264, h265. Thinking about this now, there wouldn't actually be much of a change needed :thinking_face:
This would enable:

Forwarding these JPEG encoded frames as an MJPEG HTTP stream for instance (think IP camera)
Not needing to do the actual JPEG compression on device (think low cpu usage)
And realtime streaming
MJPEG is used quite a lot for this kind of streaming but I'm not sure how HTML5 handles h264/h265 streaming. As far as I know it doesn't play well natively yet. There is some HLS apple thingy, but otherwise no standard, works everywhere.

Either way I think an option to do JPEG instead of h264/h265 would be quite easy to do and the video packets arriving to host would then be jpeg encoded frames ready to be streamed further if deemed necessary.

This is all now integrated into the develop branch https://github.com/luxonis/depthai/tree/develop.  Relevant PR: https://github.com/luxonis/depthai/pull/79


generic type extends has TS2416 error

TypeScript Version:  2.7.2
Code
export abstract class WorkflowStepBase {
    public id : number;
    public name: string;

    public abstract body: { new(): StepBody; };
    public outcomes: Array<StepOutcome> = [];
    public children: Array<number> = [];
    public errorBehavior : number;
    public retryInterval : number;

    public inputs: Array<(step: StepBody, data: any) => void>;
    public outputs: Array<(step: StepBody, data: any) => void>;

    public initForExecution(executorResult: WorkflowExecutorResult, definition: WorkflowDefinition, workflow: WorkflowInstance, executionPointer: ExecutionPointer): any {
        return ExecutionPipelineDirective.Next;
    }

    public beforeExecute(executorResult: WorkflowExecutorResult, context: StepExecutionContext, executionPointer: ExecutionPointer, body: StepBody): any {
        return ExecutionPipelineDirective.Next;
    }

    public afterExecute(executorResult: WorkflowExecutorResult, context: StepExecutionContext, stepResult: ExecutionResult, executionPointer: ExecutionPointer) {
    }

}

export class WorkflowStep<T extends StepBody> extends WorkflowStepBase {

    public body: { new(): T; };

    public inputs: Array<(step: T, data: any) => void> = [];
    public outputs: Array<(step: T, data: any) => void> = [];

}

Expected behavior:
Actual behavior:
has compile error:
/home/code/next/node_modules/workflow-es/build/src/models/workflow-step.d.ts(29,5): error TS2416: Property 'inputs' in type 'WorkflowStep<T>' is not assignable to the same property in base type 'WorkflowStepBase'.
  Type '((step: T, data: any) => void)[]' is not assignable to type '((step: StepBody, data: any) => void)[]'.
    Type '(step: T, data: any) => void' is not assignable to type '(step: StepBody, data: any) => void'.
      Types of parameters 'step' and 'step' are incompatible.
        Type 'StepBody' is not assignable to type 'T'.
/home/code/next/node_modules/workflow-es/build/src/models/workflow-step.d.ts(30,5): error TS2416: Property 'outputs' in type 'WorkflowStep<T>' is not assignable to the same property in base type 'WorkflowStepBase'.
  Type '((step: T, data: any) => void)[]' is not assignable to type '((step: StepBody, data: any) => void)[]'.
    Type '(step: T, data: any) => void' is not assignable to type '(step: StepBody, data: any) => void'.
      Types of parameters 'step' and 'step' are incompatible.
        Type 'StepBody' is not assignable to type 'T'.

Related Issues:
tsconfig.json:
{
    "compilerOptions": {
        "allowJs": false,
        "allowSyntheticDefaultImports": true,
        "baseUrl": "./../../",
        "declaration": true,
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "lib": [
            "DOM",
            "ES2016",
            "ES2017"
        ],
        "module": "commonjs",
        "noImplicitAny": false,
        "noLib": false,
        "noUnusedLocals": false,
        "removeComments": true,
        "strict": true,
        "strictPropertyInitialization": false,
        "target": "ES2015"
    },
    "include": [
        "*.ts",
        "**/*.ts"
    ],
    "exclude": [
        "./**/*.spec.ts",
        "./../../node_modules"
    ]
}

Could you provide a complete example? Preferably a minimal one that doesn't refer to so many outside types.

Yes, of course, in my project https://github.com/notadd/next, in package workflow, i referenced package workflow-es, but it always has this error on compile

The situation is basically:
interface I { x: number; }
interface A {
    cb: (x: I) => void;
}
interface B<T extends I> extends A {
    cb: (step: T) => void;
}

Why is it a compile error for B to extend A? Because then you could do this:
const b: B<J> = {
    cb(j: J) {
        assert(typeof j.y === "number");
    }
};

const a: A = b; // If this wasn't an error...
a.cb({ x: 0 }); // You could do this, which fails the assert.

function type can not use extended type, only can be the original type?

Right, because having a callback taking a T makes the class contravariant in T.
As for fixing your situation, is the base class even needed? You could just move the contents of WorkflowStepBase into WorkflowStep, replacing StepBody with T.


Move utils, builder under master

Purpose of the pull request

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

LGTM


Unacked messages in queue

Affects Version(s): <2.0.5.RELEASE>

Hi,
My team is encountering issue in our rabbitmq consumer that happens rarely. We are running multiple instance of our spring-boot application in PCF with autoscaler and tried to replicate this several times by scaling it up/down but it was unsuccessful.
It seems that there is a similar issue before with different scenario:
Unacked messages when using SimpleMessageListenerContainer (https://github.com/spring-projects/spring-amqp/issues/694)
Here is the sample consumer listener that we have, maybe we are missing configurations or something.
 @StreamListener(Constants.QUEUE_RECEIVER)
 public void queueReceiver(Payload payload) {
        log.info("[MQReceiverService] Received event | payload = {}", JacksonUtil.getInstance().writeValueAsString(payload));
        < . . . >
 }

Note that the queueReceiver didn't actually received the message as there are no logged logs. Maybe the message was stuck somewhere in the process.
Configuration:
spring:
  cache:
    type: none
  cloud:
    stream:
      bindings:
        queueReceiver: #Receive
          contentType: application/json
          destination: upload-doc
          group: upload-group.queueReceiver
          binder: rmq
      binders:
        rmq:
          type: rabbit
      rabbit:
        bindings:
          queueReceiver: #Receive
            consumer:
              requeue-rejected: true
              bindingRoutingKey: document.upload.complete
  rabbitmq:
    requested-heartbeat: 30

I also created a question in stackoverflow, (https://stackoverflow.com/questions/63465726/pcf-rabbitmq-unacked-messages-in-queue)
Thank you!

Please see my answer on Stack Overflow - it is a waste of our time and yours to ask in multiple places (and GitHub issues are not for questions anyway).


[1.10.2] Out of date Mekanism API

Hello, Mekanism just updated their MC 1.10.2 version, and they have changed the there classes a bit.
Crash log: https://pastebin.com/8YD8zb0y
I appreciate they have only just updated their mod like 30 mins ago haha but i wanted to make sure it was posted here so you were aware of it :D

Same

This is the changeset in question: https://github.com/aidancbrady/Mekanism/commit/cf6a04a65daa413179e777a19bb9f7a8ba5c30e0

This looks like a pretty simple fix. I was going to take a stab at it and submit a PR, but it doesn't look like the source for the 1.2.5 made it up.

Can confirm this.

Crashing should be fixed by using the new Mek build. https://minecraft.curseforge.com/projects/mekanism/files/2455227
Any functionality that depends on it though will require the FN update.

Fixed in dev

@SonarSonic Nice great work, is the a ETA to when this will be available on Curse

@MJRLegends Posted it just now, should be passed by curse in the next 10 mins

Great thank you


feat(package): list packages

closes #7
xst package list [options]

List installed packages

Options:
      --version               Show version number                                          [boolean]
      --config                configuration to use
      --help                  Show help                                                    [boolean]
  -G, --color                 Color the output                            [boolean] [default: false]
  -V, --versions              Display installed version                   [boolean] [default: false]
  -e, --extended              Display more information for each item      [boolean] [default: false]
  -t, --typesort              Sort by type                                [boolean] [default: false]
  -T, --timesort              Sort by installation date                   [boolean] [default: false]
  -r, --reverse               Reverse the order of the sort                                [boolean]
  -a, --app, --applications   Only list installed application packages                     [boolean]
  -l, --lib, --libraries      Only list installed library packages                         [boolean]
      --date                  Show installation date                       [choices: "short", "iso"]
  -D, --deps, --dependencies  Show package dependencies                   [boolean] [default: false]
      --fullUri               Use full URIs for display                   [boolean] [default: false]
      --raw                   Return raw JSON data from query             [boolean] [default: false]

Implements all options in #7 and then some. Except the ability to filter the list using a globbing expression.
This should rather be done as a separate command xst package info <package-abbrev>.

example output of the templating library with --extended
templating
Title: eXist-db HTML Templating Library
URI: http://exist-db.org/html-templating
Author: eXist-db Project
Description: This package contains the HTML templating library for eXist, which was previously part of the now deprecated 'shared-resources'
Website: https://github.com/eXist-db/templating
Version: 1.1.0
Installed: 2023-01-04T17:05:21.129+01:00
Processor: existdb >=5.2.0
Type: library
License: LGPL-2.1
Components:
  xquery:
    http://exist-db.org/xquery/html-templating
    http://exist-db.org/xquery/html-templating/lib

Example output of xst package list --app --date --versions --dependencies
dashboard           2.0.9  Jan  4 17:05
├── http://www.functx.com >=1.0
└── http://exist-db.org/apps/existdb-packageservice >=1.3.8
eXide               3.4.0  Jan  4 17:05
└── (no dependency)
exist-documentation 5.4.0  Jan  4 17:05
└── http://exist-db.org/html-templating >=1.0.2
fundocs             1.2.0  Jan  4 17:05
└── http://exist-db.org/html-templating >=1.0.2
monex               3.0.5  Jan  4 17:05
└── http://exist-db.org/html-templating >=1.0.2
packageservice      1.3.14 Jan  4 17:05
├── http://www.functx.com *
└── http://exist-db.org/xquery/semver-xq *

Example --extended output for functx
functx
Title: FunctX library
URI: http://www.functx.com
Author: Priscilla Walmsley
Description: The FunctX XQuery/XSLT 2.0 function library is a set of reusable functions for XQuery 1.0 and XSLT 2.0. The project itself is an open source application and framework for developers to create function libraries.
Website: http://www.functx.com/
Version: 1.0.1
Installed: 2023-01-06T21:41:14.261+01:00
Processor: any
Type: library
License: GNU-LGPL
Components:
  xslt: http://www.functx.com/functx.xsl
  xquery: http://www.functx.com

--raw can be used to pipe the json result to jq
xst package list --raw | jq '.packages[0]' -M

{
  "date": "2023-01-04T17:05:22.989+01:00",
  "processor": {
    "uri": "http://exist-db.org",
    "min": "5.3.0-SNAPSHOT",
    "max": null,
    "template": null,
    "exact": []
  },
  "components": {
    "xslt": [],
    "xquery": [],
    "xproc": [],
    "xsd": [],
    "rng": [],
    "schematron": [],
    "nvdl": [],
    "resource": [],
    "jar": []
  },
  "website": "https://www.github.com/exist-db/documentation",
  "abbrev": "fundocs",
  "target": "fundocs",
  "description": null,
  "type": "application",
  "uri": "http://exist-db.org/apps/fundocs",
  "authors": [
    "eXist-db"
  ],
  "version": "1.2.0",
  "title": "XQuery Function Documentation",
  "dependencies": [
    {
      "uri": "http://exist-db.org/html-templating",
      "min": "1.0.2",
      "max": null,
      "template": null,
      "exact": []
    }
  ],
  "license": "GNU Lesser General Public License, version 2.1"
}

In this raw output, "template" is again a bit misleading. Best to call the properties what they are in the spec: semver-min, semver-max, semver, versions, and name.

URI: also doesn't conform to the spec. The property is @name, not @uri. In public-repo, we use "Name (URI)" to distinguish the @name property from the package's <title>. I'd suggest either Name: or Name (URI):. (The package spec says the property is an IRI, but in practice I've only ever seen URIs... not to say I can tell you what the difference is without googling.)

I will rename uri to name. I think that is sensible to do as it is in fact a free-text property.

In this raw output, "template" is again a bit misleading. Best to call the properties what they are in the spec: semver-min, semver-max, semver, versions, and name.

I asked about a better name for template above :)
Property names in JSON with hyphens are possible, but I would want to avoid them as it makes it less comfortable to work with in JS. It is also somewhat uncommon.
We could either

camelCase them (semverMin, semverMax, semver, versions)
shorten them (min, max, range, versions)

I do see the value of staying close to the input XML, but it is already aggregated. components.xquery for example combines the information from expath-pkg.xml and exist.xml to show all registered module names in one place.

The property names of dependencies now reflect the attribute names of declared dependencies @joewiz (see updated --raw output).

@joewiz all suggested changes are now implemented. The package itself still had a uri property which is now renamed to name.
Also the command line flag --full-uri was renamed to --full-name


Feature Request: Discord integrations (Webhooks and bots)

Does not fit into the scope of Nextron.


1303 support gpkg without srs

see https://github.com/CartoDB/support/issues/1303#issuecomment-365580633 for reference

It doesn't :)
Thanks!


Remove duplicated typedef in array-class-stl.md

It looks that Myarray is declared twice. Should we remove one of them?

@europeanplaice : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@TylerMSFT - Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
#assign:@MicrosoftDocs/public-repo-pr-review-team

The following users don't have valid GitHub IDs, or are not collaborators on this repo: microsoftdocs/public-repo-pr-review-team

#sign-off


[docker] port docker.containers.running.total & .stopped.total metrics

These metrics were added in agent 5.20 to help on high-churn hosts where the server-side sum might be off

Faster than the CI! 🙇


Possibility to implement waterfall style(Pinterest-like) with the CompositionalLayoutSectionProvider closure?

Thanks for the nice attempt to integrate UICollectionView with SwiftUI.
I've recently been writing a waterfall page in SwiftUI (similar to Pinterest), and rather than using a series of hacks, I prefer to plug the native UICollectionView into the SwiftUI View, as you did before.
But I haven't found an efficient way to use the new API UICollectionViewCompositionalLayoutSectionProvider closure to achieve a perfect waterfall page, and I wonder if you have some ideas or thoughts to achieve it. Much appreciated for your reply.

I am not sure that the compositional layout API is the best choice when your layout depends on the size declared by the items to be displayed (which I assume is what you mean by Pinterest-like layout). AFAIK the compositional layout API can be used to describe a layout based on absolute sizes or on relative sizes between layout levels (groups and nested groups), but in a way that does not rely on the data to be displayed itself.
In your case I am therefore not convinced that using the compositional layout section provider (and thus my implementation of a SwiftUI collection) is a viable approach. You probably need a custom UICollectionViewLayout subclass implementing your content-based layout, and assigned to a UICollectionView you display directly.
This does not mean that you have to give up SwiftUI entirely, though. You can namely design cells in SwiftUI and wrap them into UIKit (as I do in my SwiftUI collection view implementation). Your collection view itself can be wrapped into SwiftUI as well (using UIViewControllerRepresentable or UIViewRepresentable) for display. Collection view updates can be triggered by an ObservableObject view model in a reactive fashion if you apply updates through a diffable data source. But of course this is more work you might have expected in the first place, and maybe what you mean by series of hack.
If you are interested I can try to sketch this idea a bit more, but this is something that would deserve an entire article to be properly discussed. This is the approach we use in our app, without any top-level SwiftUI wrapping, though (as we manage the navigation entirely in UIKit), so I can provide you with hints about how this can be achieved.

I do agree with your consideration of UICollectionViewCompositionalLayout. Its key role is to simplify the process of building a single UICollectionView which can contain lots of nested groups with just a small and robust amount of codes, instead of nesting many UICollectionView subclasses into the parent container as most developers did before iOS13.
However, these nested groups's layout can only be described on absolute or regular relative sizes,  isolated from the cell item data source, and actually it's layout looks like a set of UICollectionViewFlowLayout implementations
So the way to achieve Pinterest-style collection view layout in SwiftUI:

Create a UICollectionViewLayout custom subclass and implement custom cell layoutAttributes provider, e.g., CHTCollectionViewWaterfallLayout.
Integrate the custom layout with UIViewRepresentable, and expose the data source and cell view content provider to SwiftUI.
Optimize the data source diff process.

Yes, that means you cannot use compositional layouts and that you cannot use my SwiftUI collection view implementation as it is currently implemented.
Moreover, and though wrapping a UICollectionView into SwiftUI is fun and insightful, it is much simpler, safer and efficient to avoid it IMHO. This is something I want to write an article about in the future, but the issue with wrapping a heavy component like UICollectionView into a SwiftUI view (and exposing data source and cell providers to SwiftUI) is that this requires optimization tricks to mitigate the cost of applying incremental changes. Not to mention that you somehow must persist the state during the lifetime of the SwiftUI view with a coordinator, which also requires some tricks.
What I therefore prefer to do nowadays:

Create a view controller displaying the UICollectionView.
Create a cell provider and assign the layout in the view controller implementation (e.g. with a custom layout or a declarative compositional layout).
Have the view controller own a diffable data source to drive collection view updates in a reactive manner.
Instantiate a view model in the view controller and respond to its updates by applying corresponding snapshots to the diffable data source. I usually implement the view model as an ObservableObject, register to some @Published property publisher which broadcasts view model updates, and apply the data source snapshot when an update is received (with a sink).

Of course this view controller itself can be wrapped into a UIViewControllerRepresentable to be inserted into SwiftUI view hierarchies directly. But the idea is not to define the collection view itself in a declarative manner in SwiftUI code: Though this is tempting (and fun) there are definitely pitfalls which, after more careful consideration, are probably not worth the trouble.

Considering these existing SwiftUI View lifecycle management issues(such as the fake onAppear), UIViewControllerRepresentable is better than UIViewRepresentable.
Moreover, after writing a series of SwiftUI code, considering the increasing cost and its limited capability, I actually should not use SwiftUI as the main entry of an app, but use traditional AppDelegate and ViewController as entry and
view container, then use HostingController to embed various SwiftUI Views into the parent container.


Add gRPC for production

When starting with gRPC there are many resources setting out what gRPC is, where it originated from and how to create a basic service and client but deployments to production are not discussed and available resources are sparse. This project will help to provide the core requirements for a production-ready gRPC communication

@googlebot I signed it!

Hello, thanks for the PR! As per contribution guidelines, can you please make link additions at the bottom of the relevant section.

@bojand Done!


This is still a long way from a working tool, but I think this PR is good to go as a next step.

Will review tomorrow.


Store block positions during upgrades

Blocks workspace upgraders sometimes operate on the workspace in XML
form rather than workspace form. When we did the Blockly update in May
2017, we moved updating the positions of blocks to occur immediately
before the first render of the workspace rather than at workspace load
time. This results in all blocks being at 0, 0 if the project relied
on a component where the upgrader used XML because the blocks do not
get positioned until after the upgrade has run.
This code wraps the blockToDOMWithXY function to update the position
of the block during serialization to XML if rendering is turned off,
i.e. we are loading the workspace.
Fixes #920
Change-Id: Ie19cbe4207e6c36979c2adb767748bb54def4551

This is to fix an issue where upgraders that perform operations by transforming the workspace back into XML from Blockly didn't persist the block position information, which we deferred to the end to prevent triggering multiple rendering passes during upgrades. You can test this by loading the MoleMash app from our website. Prior to the fix the blocks will be all located at 0,0. After applying the patch and reloading the project, the blocks will be positioned correctly.

Note that this is also up on gerrit as change set 2123.

Superceded by #931 (updated to include a unit test in Mole Mash).


Non-embedded app issue

Hi there, is it possible to make the app not embedded in the Shopify admin? I tried disabling the Embed in Shopify admin setting but when I load the app the following occurs:

A new window is opened.
The index page loads for less than a second.
Some redirect happens and now the Shopify 404 page is shown.

Below is the URI generated:
https://pasartap-dev.myshopify.com/admin/apps/e1ef58708fea1eee57e4b47ba6635a05/?hmac=b79e691545e56d13d4273f50f4a20cee2bb8ff414314fae465292a95d0058fc1&shop=pasartap-dev.myshopify.com&timestamp=1520584470
Appreciate any help, thanks.
Razaly

Hey
This package doesn't have support for the legacy method. I'll have to see what I can do to add the support in, shouldn't be much. I think essentially because the ESDK JS is in the layout file it's attempting to redirect and load your app into the iframe.
I'll check it out this week and see what I can do to add the support.

@pasartap v2.1.0 should fix your issue. Update to 2.1.0 then added SHOPIFY_ESDK_ENABLED=0 to your environment and it should work as expected.

I believe this issue should be fine now. I'll close for now. If it is not, feel free to open but in my tests (code and physical) this new addition works as expected :)

Thanks!

Hi, does this support non-embed app?
If yes, is there any guide to do it?
Thank you

Hi Tyler,
(https://github.com/osiset/laravel-shopify/issues/16#issuecomment-372130638)
This is not working in latest version, Can you please help me to solve this.


[DS-3037] Fix completeStep workflow detection

https://jira.duraspace.org/browse/DS-3037

@KevinVdV can this same logic be used in other classes that also do an "if (workflow type) then" logic?  I see the same logic in all these classes (i.e. not just CompleteStep):

https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/xmlworkflow/V5_0_2014_11_04__Enable_XMLWorkflow_Migration.java#L56
https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/xmlworkflow/V6_0_2015_09_01__DS_2701_Enable_XMLWorkflow_Migration.java
https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/DatabaseRegistryUpdater.java#L73
https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect/administrative/collection/AssignCollectionRoles.java#L250
https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect/administrative/FlowContainerUtils.java#L505
https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/resources/aspects/Administrative/administrative.js#L2694

So, while I think your fix is worthwhile, I think it's incomplete. We need to analyze all these calls and at a minimum fix the others that call ConfigurationManager.

+1, as is, this PR fixes the NPE at the end of the submission process

@tdonohue I agree we need to change the other places as well & if possible attempt to remove the property from the workflow.cfg file.
When testing on fixing these issues I also noticed that the XmlWorkflow is currently broken due to the misuse of the ConfigurationManager during sql migration. I will attempt to fix this as well.
Marking this as in progress.

@KevinVdV In the meanwhile I cretaed DS-3061 and #1301. I'll cherry pick your PR on my to merge them. I greped through the whole code for "workspace.framework" and touched all relevant lines of code.

@KevinVdV , I'm closing this PR, as your sole commit here has been cherry-picked into #1301 (which was just merged to master).  Please open up a new PR as needed to solve any remaining SQL migration issues.


Statusbar under quickfix window

Feature description
Love the plugin.
How do you keep your status bar under the quickfix window?
Describe the solution you'd like

Additional context
No response

Nvm had to set set laststatus=3 instead of 2


PivotTable is frozen after save HTML as

Hello,
We have developped and interface in our SQL tool to export results of SQL queries in an HTML page using PivotTable.
Our problem is that after

opening the demo page
moving columns, changing filters, changing rendering
saving the page as a new page
opening the saved page
user modifcations first appear
and then display is reset to initial pivot table (and looses user modifications).
saved pivot table can be used

Note that saving
http://nicolas.kruchten.com/pivottable/examples/mps_prepop.html as a new html file, keeps user rendering modifications but with a "frozen" PivotTable
Is it possible to save user rendering and keep PivotTable usable without having to save configuration manually as explained in
http://nicolas.kruchten.com/pivottable/examples/onrefresh.html
?
Here is our html page code:
<!DOCTYPE html>

	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>Pivot Demo</title>
        <link rel="stylesheet" type="text/css" href="./PivotDemo_files/pivot.css">

Pivot demo with preloaded data.

Input table:

pivotInputTable.js:
document.write('
')
document.write('

')
document.write('id	SRC1	TGT1	')
document.write('

')
document.write('
')
document.write('
1	1
')
document.write('
1		1
')
document.write('

')

There are a few things happening here:

When you use File > Save as... what you get (in Chrome, at least) is a full serialization of the DOM, so the pivot table you first see is what was saved. What then happens is that the Javascript runs and overwrites the table with the newly-rendered, non-customized table.

The demos all work with $.getJSON() to load the data, which will not work if you try to load a local file (browsers do not support this kind of request for file:/// requests). This means that the first part of the above point works (the table is rendered) and the second fails (check your Javascript console, you'll see that pivotUI() is not actually called due to the failure of $.getJSON())

In general, then, this is going to be quite tricky to make work with just the browser's Save-as functionality and you will have to find a way to store the user settings JSON object somewhere in the DOM and get the saved file to use that if present.

We don't use JSON as we store data as a table, but this is not changing the fact that we won't be able to simply use the browser save-as functionality ...
Thanks for you answer and for PivotTable.js

Oh I meant the JSON settings which are passed back to you in the onRefresh callback. If you store those in the DOM somewhere and have the Javascript use those settings if present, you may be able to use Save-as after all...


Central location for transforms

Data transform classes for various models are included in their own folders in pl_bolts/models. It may be better to have them in pl_bolts/transforms instead.
Issue discussed with @otaj

I was going to suggest the same thing. Also, at least SimCLR and MoCo can use the same transforms. Maybe we want to provide some transforms that can be used to replicate the paper results on some dataset, but do we want to provide a separate set of transforms for every model and every dataset?

In general, I think the existing transforms are based on what the original papers specified (for whatever datasets they used). If a model by default uses transforms from another (i.e. BYOL using SimCLR transforms), I think we can just import SimCLRTransforms for BYOL instead of creating a copy and calling it BYOLTransforms. I think creating transforms for every model for every dataset might be too much though.
I'm all for standardizing how transforms are set up. I'm almost done moving everything over to pl_bolts/transforms so I'll let you know when I'm finished with that.

Hi, @matsumotosan, that would be great, thank you for kicking it off!

All self-supervised transforms have been moved #905

Commenting so this issue doesn't get closed.
All changes have been made in #905. Waiting for CI to be fixed so we can finish testing.


Docs: Update data standard

Pull Request Test Coverage Report for Build 98

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

Totals

Change from base Build 96:
0.0%

Covered Lines:
557

Relevant Lines:
703

💛  - Coveralls

I suggest changing the format of the content


Exchanging .dist files

A while ago, I figured the *.dist files existed for the ELK stack and other use cases, all of which were removed. Therefore, I deemed a quality of life improvement worthwhile.
I assingned you here @erik-wramner, because although I searched the whole repository for remains of *.dist-file-usage, I couldn't find any, but that doesn't mean there isn't a reason these files exists. If there is anything a overlooked, please tell me.
I cannot assign you @martin-schulze-vireso and @casperklein, but would like to hear your opinion too:)

I feel like for our template, we can afford using the latest version. People who run old versions have this file already written with the correct version. This shouldn't be an issue.


Changes in time zones in a given location?

There is a small number of locations that change time zone boundaries over time. Is there a way to get timezone offset at a given point in time for such locations?

You want to obtain the timezone a location had in the past? This is unfortunately not natively supported by this package. You could theoretically parse different versions of the timezone data and look up the timezone of the different "points in time". If you know the locations you are interested in advance (fixed) however, I guess the change of timezones of those locations can be figured out directly in a more convenient way (should be documented "officially" somewhere). Hope I could help.

Thank you for the quick feedback! Yes, I am trying to figure the timezone offset of a fixed location in the past, and I think dateutil might give that: https://dateutil.readthedocs.io/en/stable/_modules/dateutil/tz/tz.html
This would only work if timezone label (which I can get with your package) is persistent over time, so this might not work for some locations (e.g. Russia).


Update nano test network

Fix minor bugs, and add network.sh script to simplify standing up the network
Note: the updated peerNadmin.sh scripts no longer create or join a channel and now only configure the environment for the relevant peer
Signed-off-by: James Taylor<EMAIL_ADDRESS>

@denyeart I think this PR looks pretty good.  Nice updates.  Can you make a second pass to double-check it's in line with where you were headed with the nano bootstrap scripts?


about Python 2 and 3 compatibility(unicode issue)

Hi,
in the commit e87a451904c30c57c2769a7ce5477d4539055dda ,
the compatibility issue and the solution(unicode->bytes) was suggested,
but I think the code(pycocotools/coco.py) revised back again(bytes->unicode).
Is there any reason?

Thanks for pointing that out. Fixed with commit 9eb8a0a9e57ad1e592661efc2b8964864c0e6f28


"R development" under PyCharm

Under PyCharm, the typical uses states "R development". It should be "Python development".

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 8778f8e7-6c71-3c90-e6d3-05ef74aefa23
Version Independent ID: 4467059d-b8e9-2f3d-f559-dbd2b028f834
Content: Data Science Virtual Machine development tools - Azure
Content Source: articles/machine-learning/data-science-virtual-machine/dsvm-tools-development.md
Service: machine-learning
GitHub Login: @gopitk
Microsoft Alias: gokuma

@ymnliu Thanks for the feedback, I have fixed it and you should see the change shortly.

@ymnliu We will now proceed to close this thread. If there are further questions regarding this matter, please respond here and @YutongTie-MSFT and we will gladly continue the discussion.


hackrf: 2022.09.1 -> 2023.01.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/greatscottgadgets/hackrf/releases.
meta.description for hackrf is: An open source SDR platform
meta.homepage for hackrf is: https://greatscottgadgets.com/hackrf/
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2023.01.1 with grep in /nix/store/2syi6vdhbj0wxqmc0dz34f034mvfhsh7-hackrf-2023.01.1
found 2023.01.1 in filename of file in /nix/store/2syi6vdhbj0wxqmc0dz34f034mvfhsh7-hackrf-2023.01.1

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

24 total rebuild path(s)

24 package rebuild(s)

First fifty rebuilds by attrpath
cubicsdr
dump1090
gnuradio3_8Packages.ais
gnuradio3_8Packages.osmosdr
gqrx
gqrx-gr-audio
gqrx-portaudio
hackrf
kalibrate-hackrf
openwebrx
pothos
python310Packages.soapysdr-with-plugins
python311Packages.soapysdr-with-plugins
qradiolink
rtl_433
sdrangel
sdrpp
sigdigger
soapyhackrf
soapysdr-with-plugins
srsran
suscan
urh
welle-io

Instructions to test this update (click to expand)

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

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

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

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

24 packages built:

cubicsdr
dump1090
gnuradio3_8Packages.ais
gnuradio3_8Packages.osmosdr
gqrx
gqrx-gr-audio
gqrx-portaudio
hackrf
kalibrate-hackrf
openwebrx
pothos
python310Packages.soapysdr-with-plugins
python311Packages.soapysdr-with-plugins
qradiolink
rtl_433
sdrangel
sdrpp
sigdigger
soapyhackrf
soapysdr-with-plugins
srsran
suscan
urh
welle-io

Maintainer pings
cc @sjmackenzie for testing.

@GrahamcOfBorg build kalibrate-hackrf soapyhackrf sdrangel


18w46a

Changed the protocol id and updated the block, blockstate and item mappings. Packets and sounds did not change.

Ty Gerry :)


Refactor the architecture to add support for running the test cases in subprocesses

Hi,
I'm making this pull request to coordinate the implementation of the test case execution in subprocesses. The goal is to highlight the prototype code I've already done and compare it to the current code. This will allow me to point out the problems I had to deal with and the solutions I found. I'm pretty sure there are still things that can be improved because I was fairly new to the codebase when I started this branch and there are surely things that can be optimized so don't hesitate to make comments.
An architecture based on observers
The current architecture of Pynguin is based on observers for calculating various information. This makes Pynguin very flexible and configurable but it complicates execution in subprocesses. Indeed, it's rather complicated to call a main process observer from a subprocess because a link has to be made at some point, and data has to be transferred with each call.
That's why I chose a different approach in my prototype. I noticed that all observers interacted mostly with test cases and results. This is due to the fact that there was a constraint in their specification that limited their memory to the thread they were in for certain methods. By extending this constraint slightly to say that it applied to threads or subprocesses now, this almost made it possible to send them to another process, since all the data manipulated would remain included in their memories and in the results, which was going to be sent back to the main process anyway. The problem was that some observers also used other data in some methods. However, the use of this other data was limited to the after_test_case_execution_outside_thread functions. This is why I came up with the idea of splitting the observers into 2 parts, the part that will be executed on the main process (ExecutionObserver), where we'll call after_test_case_execution_outside_thread, and the part sent and executed on the subprocess (RemoteExecutionObserver) with the rest of the methods.
This has several advantages:
Firstly, this would allow Pynguin to continue working in the same way as before if we don't want to use subprocesses. In this case, we just need to run the RemoteExecutionObserver on the main process and everything will work in the same way.
Secondly, it limits the amount of information exchanged, as we only need to send the remote observers and don't need to send all the data used by the entire observer.
Finally, it retains Pynguin's flexibility while allowing observers to be executed in subprocesses.
(Note: I've renamed the observer methods to better match the new names)
Current Architecture

Prototype Architecture

A fairly complex data transfer
The current class architecture was not designed to be sent from one process to another. As a result, there are references between classes all over the place, and sending an object using pickle sometimes means sending all the data that Pynguin manipulates. Fortunately, when a new process is created, the memory is copied directly without going through pickle, which allows us to transfer data that pickle doesn't support and to be faster. However, the problem arises when transferring data from the subprocess to the main process. Indeed, this transfer has to be carried out using pickle and, with all the references, there's a big bottleneck which means that a lot of data has to be copied, and this sometimes causes crashes as some types just can't be serialized using pickle. This can be partly mitigated by using dill, which is a pickle extension that supports more types, but it doesn't fix everything.
In my prototype, I managed to make everything necessary serializable using dill, but the best thing would be to redesign the data that needs to be sent so that this doesn't happen.
In addition, there's a special case concerning the tracer. For the moment, the tracer is installed when the target module is imported. However, during the memory copy to create the subprocess, the tracer is also copied, except that its reference becomes different from the one I'm passing as an argument to the function executed in the subprocess. Therefore, I have to modify it after the execution of the subprocess to be able to retrieve the information that the tracer obtained during the execution of the test case. It's annoying, but the other solution, which consisted in reinstrumenting the module after executing the submodule, created a big loss of performance, so it just wasn't acceptable.
Some necessary improvements
At the moment, the creation of error-revealing test cases is very ugly, they're created on the fly and they're not minimized to make it easy to find the bug. I think it would be interesting to handle them better, but that would mean tweaking the algorithms, and I didn't have the time back then.
Note
The src/pynguin/instrumentation/tracer.py file is mainly composed of classes that have been transferred from the src/pynguin/testcase/execution.py file because there were circular imports and this is why there are so many line changes.
Refactoring plan
I don't think it would be a good idea to merge this entire pull request at once, so I suggest that we do certain steps in other pull requests to better test and discuss each addition. In order, I suggest that we do the following:

Refactor the tracer to allow easy changes and avoid recursive imports later.
Add an execute_multiple function to execute a list of tests at once. For the moment, this won't change the behavior, but it's an important function for speeding up the subprocess execution.
Refactor the observers to have remote observers.
Optimization of the results that are sent back to the subprocess.
Add the subprocess executor (in this branch).

What do you think of this plan?
Don't hesitate to criticize or validate certain parts so that I can implement them ! 🙂

Hi @BergLucas ,
This is an impressive and remarkable work!   I am happy to discuss options and possibilities, because I think it would be nice to have this functionality in Pynguin.
One question: if I want to run this, I just have to add the --subprocess flag?

Shall I do yet another run to collect some data on the behaviour, comparing the current execution, and the one from this PR?

This PR just contains the code that had already been benchmarked against the classic execution that we discussed in issue #74, but where the few bugs I had found had been corrected. So, we could do another benchmark, but its usefulness would be limited for now. I think it would be more interesting to do a benchmark later to check that the refactoring hasn't caused any loss of performance on classic execution and to compare the performance of my prototype with the performance of the final code where data transfer has been optimized.

That's fine for me as well, I'd have suggested to benchmark this anyway at some point, to be sure we do not introduce any issues in existing code.
Do you already have plans how you want to integrate this into main?  You know the changes best; I'd argue that rebasing it to main/merge main into this branch would be necessary to resolve the merge conflicts, however, we could also do some incremental approach.


Feature request: Sync new dir creation

Would it be possible to sync the creation of a new local directory to the remote server? I've found that I have to run mkdir on the server and then re-sync the project locally to not get errors around new directories or files in those directories.

Renaming would be nice too.
Thanks a lot!

@aaronmoodie
so do i    it  throw  an error "no such file"   i  modify  the upload function
create sftp after exec "mkdir -p" command     in "upload" function  in "ScpTransport"
#
  c.exec "mkdir -p \"#{path.dirname(targetFilePath)}\"", (err,chan) ->
      return errorHandler err if err
      c.sftp (err, sftp) ->
        return errorHandler err if err
        sftp.fastPut localFilePath, targetFilePath, (err) ->
          return errorHandler err if err
          end()

          sftp.end()
          callback()


Interface/type changes

At the moment for (almost) each entity there are 3 interfaces - IEntity, IEntityCreate and IEntityUpdate.
The 3 interfaces are described independently of each other but create and update ones can be derived from the main interface by:

removing some of the properties
making some of the properties optional
replacing some of the properties (for example Tags should be replaced with string[] instead of ITagContensed in the entity)

Not a problem if this is not done at the end but the interfaces/types will look nicer this way

For example
export type Optional<T, K extends keyof T> = Pick<Partial<T>, K> & Omit<T, K>;

export interface ICommonCreateUpdate {
  customProperties?: string[];
  owner?: string;
  tags?: string[];
}

export type IStreamCreate = Omit<
  IStream,
  | "customProperties"
  | "createdDate"
  | "modifiedDate"
  | "schemaPath"
  | "privileges"
  | "modifiedByUserName"
  | "id"
  | "owner"
  | "tags"
> &
  ICommonCreateUpdate;

export type IStreamUpdate = Optional<
  Omit<
    IStream,
    | "customProperties"
    | "createdDate"
    | "modifiedDate"
    | "schemaPath"
    | "privileges"
    | "modifiedByUserName"
    | "id"
    | "owner"
    | "tags"
  >,
  "name"
> &
  ICommonCreateUpdate;


WIP

This all works, but the tests are failing because they're expecting slightly different APIs.
For your perusal while I fix those.

LGTM


Adds WebGL2 announcement to CHANGELOG

See https://github.com/CesiumGS/cesium/pull/10894

Thanks for the pull request @sanjeetsuhag!

:heavy_check_mark: Signed CLA found.
:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.

@ggetz Updated. Since we're replacing ContextOptions.requestWebgl2 with  ContextOptions.requestWebgl1 should we add a separate deprecation notice for that?

Yes, let's do that! It is an official part pf the API.

@ggetz Updated the PR.

Added ContextOptions.requestWebgl1
Deprecated ContextOptions.requestWebgl2
Updates CHANGES.md

Great, thanks @sanjeetsuhag!


Collapsed minimap overlaps the arrow up button

Issue Summary
The minimap overlaps the arrow up button in the action menu (footer).
Steps to Reproduce

Start a new project with wagtail start myproject
Use a small viewport width
The arrow up button is behind the minimap.

I expect this button to be fully visible.

FYI, the element has dropdown-toggle class.

YES, I have confirmed that this issue can be reproduced as described on a fresh Wagtail project.

Technical details

Python version: N/A
Django version: N/A
Wagtail version: Main
Browser version: Latest Chrome

Can I work on it?


Make use of this futex optimization when supported?

https://lkml.org/lkml/2019/7/30/1399

As far as I know this is still not available in the mainline kernel. Also, none of the synchronization primitives we expose actually require this functionality.

OK


RFC: FrontendWorkflowForm is a hack and should be removed or heavily refactored.

The current state of the "FrontendWorkflowForm" is that is has not been touched since 2012 (except by me) and does a bunch of quirky things that make routing hard to follow.
For backwards compatibility, we could just split it out into a "silverstripe-advancedworkflow-bc" branch for antiquated projects.
Moving forward, I'd prefer the underlying ObjectCreatorForm ideas presented here:
https://github.com/nyeholt/silverstripe-frontend-objects/issues/11
To also contain have WorkflowForm support in some sort of way.

Random thought: Perhaps the Form itself can become instead an Extension to add Workflow functionality to your own form.

This RFC hasn't received any traction in two years, so I'm going to close it. Thanks for raising it though!


update SST datasets

..PCMDIobs/obs4MIPs_input/MOHC
HadISST1-1 (high, greens function - here and other sources) - updated to 2023-04-12
..PCMDIobs/obs4MIPs_input/NOAA-PSL
COBE1 (high) - 2023-06-01
ERSST5 (low) - 2023-10-01
OISST2-1 (low) - 2023-10-01
..PCMDIobs/obs4MIPs_input/RSS
RSS-MW5-1
RSS-MW-IR5-1

Also adding AVISO - https://data.marine.copernicus.eu/product/SEALEVEL_GLO_PHY_L4_MY_008_047/services (Copernicus)

Closed as now dupe of #11


[No Ticket] Update reward summary to use the cost for the full quantity

📲 What
The late pledge flow shows prices for the total based on the quantity of the item in the list ex: if you have 3 items that cost $4, that would be a displayed price of $12
🤔 Why
Its more readable in terms of a price summary
🛠 How
Multiplied the price by the quantity (or 1 if no quantity available)
👀 See

📋 QA
Go to a project with add ons and add multiples of an add on
Go to the pledge fragment and confirm the correct amount for the quantity is displayed

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 67.29%. Comparing base (dec62dd) to head (911fba6).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##             master    #2013   +/-   ##
=========================================
  Coverage     67.29%   67.29%
  Complexity     2057     2057
=========================================
  Files           355      355
  Lines         21444    21444
  Branches       3021     3021
=========================================
  Hits          14430    14430
  Misses         5406     5406
  Partials       1608     1608

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


grpc 1.68.1

try to workaround issues in #397 by not updating the grpc name-resolver listener in a Scala future
there are some issues even after this - similar issues with grpc 1.68.1 enforcing that SynchronizationContext is used and that fails because we use Scala Futures
https://github.com/grpc/grpc-java/issues/11662 I suspect the changes in grpc 1.68.1 are too big for us to workaround and that we might need to get grpc team to allow config to disable some of their recent changes

the fix is included in 1.68.2

replaced by #415


re-added inmanta.module.INSTALL_OPTS and added documentation

Description
This fixes the breaking of the API used by pytest-inmanta introduced by d0959ab1.
Self Check:
Strike through any lines that are not applicable (~~line~~) then check the box

[x] Attached issue to pull request
[x] Changelog entry
[x] Type annotations are present
[x] Code is clear and sufficiently documented
[x] No (preventable) type errors (check using make mypy or make mypy-diff)
[x] Sufficient test cases (reproduces the bug/tests the requested feature)
[x] Correct, in line with design
[x] End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )

Reviewer Checklist:

[ ] Sufficient test cases (reproduces the bug/tests the requested feature)
[ ] Code is clear and sufficiently documented
[ ] Correct, in line with design

Processing this pull request

Pull request rejected by merge tool. Failed to parse change entry file: Change entry /tmp/tmp18a08n_o/changelogs/unreleased/fix-api-breaking-pytest-inmanta.yml does not match pydantic schema: 2 validation errors for ChangeEntry
destination-branches
field required (type=value_error.missing)
destination-repos
extra fields not permitted (type=value_error.extra)

Processing this pull request

Merged into branches master in 08c4c1612f41c7b2e83135e8ba6e2205f6b3a1c6

Processing #2841.


OCPBUGS-7104: Detect MCV processing error during backup/precaching

Anything other than "not found" should be treated as error.

/assign @sudomakeinstall2 @sabbir-47

/retest

/cherrypick release-4.12


Support CA Certificates with native images

When configuring a JDK or JRE, this buildpack will add any certificates provided by the CA Certificates buildpack to the JVM truststore. It does not appear that certificates provided by CA Certificates will be configured correctly when building a native image. Can support for CA Certificates in native images be added?

@scottfrederick Hi, we merged https://github.com/paketo-buildpacks/java-native-image/pull/99 recently, which sounds like it addresses your request here. I just wanted to confirm though, as this is opened up under the Graalvm buildpack. Just want to make sure I'm not overlooking somewhere else where we need to add ca-certificates back. Thanks

Hi, this request is about adding the certificates to the embedded jks keystore that is added to the executable at build time.
It is required because substrate VM doesn't support jks loading at runtime.
I have an open PR for graalVM regarding that, but in the meantime we need a way to include our internal certificates.

I was going to check if I could propose a PR here, but if you're already familiar with buildpacks please go ahead (I'm a complete n00b here).

FTR here is the graalVM PR: https://github.com/oracle/graal/pull/3091

As @matthyx said, there's more to do here for GraalVM in the native image case. Good documentation on this is hard to find, but there's a good hint in the GraalVM javadocs.
To fully support CA Certificates in this buildpack with native-image builds, I think what needs to happen is:

Certificates are read from the location the ca-certificates buildpack stores them in, converted to a Java keystore format, and stored in the image.
The system property -Djavax.net.ssl.trustStore is set to the path of the generated Java keystore file at native image compile time.

100% correct
So who's implementing it?
I'll badly need it once Spring Boot reaches 2.5.0 stable :-)

OK, thanks for the clarifications. Let me take a look at this tomorrow and see what we can do.

Hi @dmikusa-pivotal any news?

Well, the good news is that I think we are doing similar things in other buildpacks so it shouldn't be too hard to add this in here. It'll take some work but I have a couple of other priorities in my queue first, so I'd guess maybe 1-2 weeks for me to implement. If you are interested in getting it done more quickly and could send a PR, I can definitely make time to review/merge that in.

Thanks @dmikusa-pivotal I think it's fine for a timeline. You'll probably make it better and faster than me...

Certificates are read from the location the ca-certificates buildpack stores them in, converted to a Java keystore format, and stored in the image (possibly using libjvm/certificate_loader.go).
The system property -Djavax.net.ssl.trustStore is set to the path of the generated Java keystore file at native image compile time.

Digging some more, GraalVM buildpack is already running the code that should be importing container certs (and as far as I can tell, also ca-certs provided certs, into the JVM's default cacerts. The GraalVM buildpack is loading these into the keystore here.
My suspicion was that you could make this work right now by setting $BP_NATIVE_IMAGE_BUILD_ARGUMENTS='-Djavax.net.ssl.trustStore=$JAVA_HOME/jre/lib/security/cacerts' (I'm not 100% sure it'll interpret JAVA_HOME correctly, it might require the full path to the layer). I tried this a few ways and I can see it passing the -Djavax.net.ssl.trustStore argument into the command to build the image. That said, my resulting image doesn't work. It's giving me trust errors when I try to make an HTTPS connections.
I can see ca-certs buildpack running and importing my custom CA into the image. There is unfortunately no logging when GraalVM buildpack loads the container certs into the JVM default cert. I need to confirm this is happening as I expect. Failing that, I will have to poke at the native image build command a bit more. I was hoping to get this working before I start hacking at the code. It seems like the changes should be minimal, I just wanted to figure out specifically what needs to change.

Awesome news @dmikusa-pivotal I will try to find some time today to try out the trick with $BP_NATIVE_IMAGE_BUILD_ARGUMENTS and let you know!

My suspicion was that you could make this work right now by setting $BP_NATIVE_IMAGE_BUILD_ARGUMENTS='-Djavax.net.ssl.trustStore=$JAVA_HOME/jre/lib/security/cacerts' (I'm not 100% sure it'll interpret JAVA_HOME correctly, it might require the full path to the layer). I tried this a few ways and I can see it passing the -Djavax.net.ssl.trustStore argument into the command to build the image. That said, my resulting image doesn't work. It's giving me trust errors when I try to make an HTTPS connections.

OK, so I figured out what I was messing up yesterday. When I was merging updates recently, I messed up the order and the ca-certs buildpack was not running first. Thus GraalVM was running, importing the default set of certs, then ca-certs was running and adding my custom cert, but it was already too late because GraalVM had run and generated the cacerts file with the container certs. Anyway, after fixing this. It's working for me.
So I set BP_NATIVE_IMAGE_BUILD_ARGUMENTS='--enable-https -Djavax.net.ssl.trustStore=$JAVA_HOME/jre/lib/security/cacerts'. The first argument is unrelated but required if you want HTTPS to work in a native image. The second points native-image to the correct cacerts file. It does appear that $JAVA_HOME is honored here, assuming you properly shell-escape it so that it's not evaluated in your local shell.
You should be able to use this now (although you'll need a custom java-native-image buildpack image at the moment since we haven't cut a release since adding ca-certs back into the buildpack).
What I will do is automate this and have the native-image buildpack pass in this argument conditionally, based on the presence of the ca-certs binding.

The system property -Djavax.net.ssl.trustStore is set to the path of the generated Java keystore file at native image compile time.

I'm also wondering if this is really necessary. The GraalVM buildpack is loading the ca-certificates provided certs into the default truststore for the JVM, i.e. $JAVA_HOME/jre/lib/security/cacerts. I did a quick test without the -Djavax.net.ssl.trustStore argument and it seemed to pick things up just fine. My image was able to connect a server that was using a certificate signed by the bundled CA cert.
@matthyx If you could try it without the argument too. Just make sure that you see these three key items in your build output.

CA Certificates Buildpack runs before GraalVM buildpack
CA Certificates should output Added 1 additional CA certificate(s) to system truststore, or the number of certs you've bound.
GraalVM should say Adding 130 container CA certificates to JVM truststore where 130 is the default of 129 certs + the number of certs you've bound in. I bound in one, so 129 + 1 == 130.

[builder] Paketo CA Certificates Buildpack 2.2.0
[builder]   https://github.com/paketo-buildpacks/ca-certificates
[builder]   Launch Helper: Contributing to layer
[builder]     Creating /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper
[builder]   CA Certificates: Contributing to layer
[builder]     Added 1 additional CA certificate(s) to system truststore
[builder]     Writing env.build/SSL_CERT_DIR.append
[builder]     Writing env.build/SSL_CERT_DIR.delim
[builder]     Writing env.build/SSL_CERT_FILE.default
[builder]
[builder] Paketo GraalVM Buildpack 6.1.0
[builder]   https://github.com/paketo-buildpacks/graalvm
[builder]   Build Configuration:
[builder]     $BP_JVM_VERSION              11              the Java version
[builder]   Launch Configuration:
[builder]     $BPL_JVM_HEAD_ROOM           0               the headroom in memory calculation
[builder]     $BPL_JVM_LOADED_CLASS_COUNT  35% of classes  the number of loaded classes in memory calculation
[builder]     $BPL_JVM_THREAD_COUNT        250             the number of threads in memory calculation
[builder]     $JAVA_TOOL_OPTIONS                           the JVM launch flags
[builder]   GraalVM JDK 11.0.11: Contributing to layer
[builder]     Downloading from https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-21.1.0/graalvm-ce-java11-linux-amd64-21.1.0.tar.gz
[builder]     Verifying checksum
[builder]     Expanding to /layers/paketo-buildpacks_graalvm/jdk
[builder]     Adding 130 container CA certificates to JVM truststore
[builder]   GraalVM Native Image Substrate VM 11.0.11
[builder]     Downloading from https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-21.1.0/native-image-installable-svm-java11-linux-amd64-21.1.0.jar
[builder]     Verifying checksum
[builder]     Installing substrate VM
[builder] Processing Component archive: /tmp/1ab725616fede21ad5ae900d00ec6d45753db6f6f4fe51a836d538c79d79614a/native-image-installable-svm-java11-linux-amd64-21.1.0.jar
[builder] Installing new component: Native Image (org.graalvm.native-image, version 21.1.0)
[builder]     Writing env.build/JAVA_HOME.override
[builder]     Writing env.build/JDK_HOME.override
...

In my case, when these three happened, native-image just did the right thing and pull in my custom cacerts.

@dmikusa-pivotal I have tried to build a new version of the native-image buildpack and then substitute it on my docker host.
However I cannot test if that works, because paketo-buildpacks/graalvm:6.0.0 doesn't take my binding into account for the certificates and therefore fails to download the tar.gz for graalvm-ce-java11 because of our internal SSL introspection.

Here is the error:
[INFO] Building image 'docker.io/library/job-launcher:0.0.8-SNAPSHOT'
[INFO]
[INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:tiny' 100%
[INFO]  > Pulled builder image 'paketobuildpacks/builder@sha256:a5643f60ae81cd452935b213e1aae3042a61fe6d27ecbfb3f479b0888231c6b4'
[INFO]  > Pulling run image 'docker.io/paketobuildpacks/run:tiny-cnb' 100%
[INFO]  > Pulled run image 'paketobuildpacks/run@sha256:57768a9ede0bed24b6c176a673e2cc825c65ac319be0baa32661eb4db722dba3'
[INFO]  > Executing lifecycle version v0.11.1
[INFO]  > Using build cache volume 'pack-cache-66f994727480.build'
[INFO]
[INFO]  > Running creator
[INFO]     [creator]     ===> DETECTING
[INFO]     [creator]     4 of 11 buildpacks participating
[INFO]     [creator]     paketo-buildpacks/graalvm        6.0.0
[INFO]     [creator]     paketo-buildpacks/executable-jar 5.0.0
[INFO]     [creator]     paketo-buildpacks/spring-boot    4.2.0
[INFO]     [creator]     paketo-buildpacks/native-image   4.0.0
[INFO]     [creator]     ===> ANALYZING
[INFO]     [creator]     Restoring metadata for "paketo-buildpacks/spring-boot:helper" from app image
[INFO]     [creator]     Restoring metadata for "paketo-buildpacks/spring-boot:spring-cloud-bindings" from app image
[INFO]     [creator]     Restoring metadata for "paketo-buildpacks/spring-boot:web-application-type" from app image
[INFO]     [creator]     ===> RESTORING
[INFO]     [creator]     ===> BUILDING
[INFO]     [creator]
[INFO]     [creator]     Paketo GraalVM Buildpack 6.0.0
[INFO]     [creator]       https://github.com/paketo-buildpacks/graalvm
[INFO]     [creator]       Build Configuration:
[INFO]     [creator]         $BP_JVM_VERSION              11.*            the Java version
[INFO]     [creator]       Launch Configuration:
[INFO]     [creator]         $BPL_JVM_HEAD_ROOM           0               the headroom in memory calculation
[INFO]     [creator]         $BPL_JVM_LOADED_CLASS_COUNT  35% of classes  the number of loaded classes in memory calculation
[INFO]     [creator]         $BPL_JVM_THREAD_COUNT        250             the number of threads in memory calculation
[INFO]     [creator]         $JAVA_TOOL_OPTIONS                           the JVM launch flags
[INFO]     [creator]       GraalVM JDK 11.0.10: Contributing to layer
[INFO]     [creator]         Downloading from https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-<IP_ADDRESS>/graalvm-ce-java11-linux-amd64-<IP_ADDRESS>.tar.gz
[INFO]     [creator]     unable to invoke layer creator
[INFO]     [creator]     unable to get dependency jdk
[INFO]     [creator]     unable to download https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-<IP_ADDRESS>/graalvm-ce-java11-linux-amd64-<IP_ADDRESS>.tar.gz
[INFO]     [creator]     unable to request https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-<IP_ADDRESS>/graalvm-ce-java11-linux-amd64-<IP_ADDRESS>.tar.gz
[INFO]     [creator]     Get "https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-<IP_ADDRESS>/graalvm-ce-java11-linux-amd64-<IP_ADDRESS>.tar.gz": x509: certificate signed by unknown authority
[INFO]     [creator]     ERROR: failed to build: exit status 1

Sorry, let's see if we can make this easier to test.

Are you using Spring Boot tools here? In Boot 2.4, there is no support for bindings. That is new in 2.5. If you're using one of the RC's, you can set bindings https://docs.spring.io/spring-boot/docs/2.5.0-RC1/maven-plugin/reference/htmlsingle/#build-image-customization. Also, change the builder to use dmikusa/tiny-java-native, which is a testing branch I put up to make this easier.

Alternatively, can you try this?

pack build <image-name> --path target/your-file.jar -e BP_NATIVE_IMAGE=true -e BP_NATIVE_IMAGE_BUILD_ARGUMENTS='--enable-https' -B dmikusa/tiny-java-native --volume "/path/to/binding/:/platform/bindings/ca-certificates"

BP_NATIVE_IMAGE_BUILD_ARGUMENTS and --enable-https is optional, I included that because I was making HTTPS requests as a way to validate.

dmikusa/tiny-java-native is a temporary copy of the tiny builder where I have the main branch of the java-native-image included so that ca-certificates is included and in the correct order. This will go away, when I cut the next java-native-image release & our builders update.

/path/to/binding should be on your local system pointing to a directory that looks roughly like this:

binding/
├── cert-1.crt
└── type

The contents of the type file should be ca-certificates. The other files are just the certs to include. There's one in my example, but you should be able to include more.
Let me know how that goes.

Perfect, it works!
[INFO]     [creator]       https://github.com/paketo-buildpacks/ca-certificates
[INFO]     [creator]       Launch Helper: Contributing to layer
[INFO]     [creator]         Creating /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper
[INFO]     [creator]       CA Certificates: Contributing to layer
[INFO]     [creator]         Added 1 additional CA certificate(s) to system truststore
[INFO]     [creator]         Writing env.build/SSL_CERT_DIR.append
[INFO]     [creator]         Writing env.build/SSL_CERT_DIR.delim
[INFO]     [creator]         Writing env.build/SSL_CERT_FILE.default

And even builds 'till the end:
[INFO]     [creator]     Adding layer 'paketo-buildpacks/ca-certificates:helper'
[INFO]     [creator]     Adding 1/1 app layer(s)
[INFO]     [creator]     Reusing layer 'launcher'
[INFO]     [creator]     Adding layer 'config'
[INFO]     [creator]     Adding layer 'process-types'
[INFO]     [creator]     Adding label 'io.buildpacks.lifecycle.metadata'
[INFO]     [creator]     Adding label 'io.buildpacks.build.metadata'
[INFO]     [creator]     Adding label 'io.buildpacks.project.metadata'
[INFO]     [creator]     Adding label 'org.opencontainers.image.title'
[INFO]     [creator]     Adding label 'org.opencontainers.image.version'
[INFO]     [creator]     Adding label 'org.springframework.boot.spring-configuration-metadata.json'
[INFO]     [creator]     Adding label 'org.springframework.boot.version'
[INFO]     [creator]     Setting default process type 'web'
[INFO]     [creator]     Saving docker.io/library/job-launcher:0.0.8-SNAPSHOT...
[INFO]     [creator]     *** Images (575017bf258d):
[INFO]     [creator]           docker.io/library/job-launcher:0.0.8-SNAPSHOT
[INFO]     [creator]     Adding cache layer 'paketo-buildpacks/graalvm:jdk'
[INFO]     [creator]     Adding cache layer 'paketo-buildpacks/native-image:native-image'
[INFO]
[INFO] Successfully built image 'docker.io/library/job-launcher:0.0.8-SNAPSHOT'

Thank you so much for your support, now we're waiting for the 2.5.0 release.

I was already using 2.5.0-M1 and bindings, but they only worked for jvm builds.
Now with your custom image native builds work behind our proxies, and they include the proper rootCA, thank you one more time!

Fantastic! Thanks @matthyx for helping me test and work through this.
Since I didn't have to change any code here, there's no new GraalVM version to cut. We do need to cut a new release of java-native-image though, to fix the ordering issue. That is presently held up for compatibility reasons, as I mentioned here -> https://github.com/paketo-buildpacks/java-native-image/pull/99#issuecomment-828889845. In the meantime, feel free to use that temporary builder I pushed. I'll leave it published. Just make sure you switch once we cut the new release.
I'll keep this issue open until we're able to cut the new release so you can get notifications.

@matthyx Could you please share a sample application to help me writing proper documentation (tracked by https://github.com/spring-projects-experimental/spring-native/issues/689)?

Sure @sdeleuze let me fork the sample apps repo and make the modifications there... I cannot share our company apps on github.

Please see my modifications in the webclient sample app:
https://github.com/matthyx/spring-native/commit/9daa41fb6f00f789bbf556ae93ce0123bd2b2f55
You have to build it using:
mvn spring-boot:build-image

I have just tested this with springBootVersion = '2.5.0' and it only works if i convert the certificates to the PEM format using the following command: openssl x509 -in certificate.crt -inform DER -out certificate.pem -outform PEM.
 bootBuildImage {
        bindings = [
            "${project.rootDir}/bindings/ca-certificates:/platform/bindings/ca-certificates"
        ]
    }

If the certificates are in the CRT format then i get the following error:
[creator]     failed to decode certificate from file at path "/platform/bindings/ca-certificates/certificate.crt"
[creator]     failed find PEM data
[creator]     ERROR: failed to build: exit status 1

Is this expected and we should always convert to PEM ?

I think so: https://github.com/paketo-buildpacks/ca-certificates
CA certificate to trust. Should contain exactly one PEM encoded certificate.

"${project.rootDir}/bindings/ca-certificates can contain multiple CA certs, but they all have to be PEM.

+1 they have to be PEM encoded, that's a requirement of ca-certificates. If that's a challenge, or you think we should permit other formats, you could open an issue against ca-certificates.

I think this is fine from my point of view, we can convert them to be PEM encoded.

Sorry for the delay. This work was released and the latest versions of Java Native Image buildpack should support CA certificates.