Automated reporting framework (sponsored by Panasonic)

Hey everyone,
As with the previous PR, this development is sponsored by Panasonic Informations Systems Company Europe.
The idea of this framework is to allow automated reporting within DefectDojo. Reminding users about open findings, reminding owners about upcoming or done engagements etc are possible to automate with this update.
Documentation and tests have been created.
Please notice that there are some commits that are duplicate with the outstanding ones from the other PR. This is done to prevent bugs that have been fixed already and to work with a consistent state.

[X] Your code is flake8 compliant (DefectDojo's code isn't currently flake8 compliant, but we're trying to correct that.)
[X] If this is a new feature and not a bug fix, you've included the proper documentation in the ReadTheDocs documentation folder. https://github.com/DefectDojo/Documentation/tree/master/docs or provide feature documentation in the PR.
[X] Model changes should include the necessary migrations in the dojo/dd_migrations folder.
[X] Add applicable tests to the unit tests.

@JamesCullum looks like there are still some flake8 issues: https://travis-ci.org/DefectDojo/django-DefectDojo/builds/523367868?utm_source=github_status&utm_medium=notification

Hey @devGregA,
Because it's mostly minor, I didn't want to push again. Just pushed the fixes, but the invalid escape sequence is a bug within flake8 detection and I don't know of any good fix (apart from disabling this check).

@aaronweaver Probably merge this into sec_automation as well?

So whats the status on this? Can you elaborate on the closure - is it tracked somewhere else?

When the branch was renamed for the move to Python3 the PR's were automatically closed. Feel free to resubmit.


iox-#1391 Remove posix from include path and namespace in dust

Pre-Review Checklist for the PR Author

[x] Add a second reviewer for complex new features or larger refactorings
[x] Code follows the coding style of CONTRIBUTING.md
[x] Tests follow the best practice for testing
[x] Changelog updated in the unreleased section including API breaking changes
[x] Branch follows the naming format (iox-123-this-is-a-branch)
[x] Commits messages are according to this guideline

[x] Commit messages have the issue ID (iox-#123 commit text)
[x] Commit author matches Eclipse Contributor Agreement (and ECA is signed)

[x] Update the PR title

Follow the same conventions as for commit messages
Link to the relevant issue

[x] Relevant issues are linked
[x] Add sensible notes for the reviewer
[ ] All checks have passed (except task-list-completed)
[x] All touched (C/C++) source code files from iceoryx_hoofs are added to ./clang-tidy-diff-scans.txt
[ ] Assign PR to reviewer

Notes for Reviewer

Like decided in the developer meetup today, posix is not part of the include path and namespace.
Checklist for the PR Reviewer

[ ] Commits are properly organized and messages are according to the guideline
[ ] Code according to our coding style and naming conventions
[ ] Unit tests have been written for new behavior
[ ] Public API changes are documented via doxygen
[ ] Copyright owner are updated in the changed files
[ ] All touched (C/C++) source code files from iceoryx_hoofs have been added to ./clang-tidy-diff-scans.txt
[ ] PR title describes the changes

Post-review Checklist for the PR Author

[ ] All open points are addressed and tracked via issues

References

Relates to #1391

@FerdinandSpitzschnueffler @mossmaurice @dkroenke @MatthiasKillat @elfenpiff @budrus feel free to add yourself as reviewer


Fix: (modules) Fix responsive styles on features-gallery

Fix <main> overflow-x;
Fix responsive of features gallery;

🤘🤘


Update DepositTreeSnapshot as of EIPs#5443 PR

PR Description
Updated deposit merkle tree snapshot:

Currently our route is /teku/v1/beacon/deposit_snapshot. Should I move it to the /eth/v1/beacon/deposit_snapshot according to the EIP-4881
Combining blockHeight with Eth1Data lead to increase in vote and metric preparation work, should I rework it?

Fixed Issue(s)

Fixes #6062
Documentation

[x] I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

[x] I thought about adding a changelog entry, and added one if I deemed necessary.

@ajsutton updated for review

@ajsutton removed cache changes, see comment


[Backport 7.x] NameValueCollection.ToQueryString performance optimisation

Backport dff2c6a2d486978c70ad2952e037b6d2edbafa41 from #4952

CI failure fixed in another PR


Add CL:00001087 CD4+ TEMRA

Added CD4+ TEMRA and made CD8+ TEMRA changes Fixes #851

@addiehl
I noticed a minor typo in the comment "This cell type is seen human but not found in the mouse.",
should probably read "This cell type is seen in human but not found in the mouse."
:-) Thanks

@addiehl
I noticed a minor typo in the comment "This cell type is seen human but not found in the mouse.",
should probably read "This cell type is seen in human but not found in the mouse."
:-) Thanks

Thanks for pointing out the typo.

Thanks for pointing out the typo.

Fixed the typos for both CL:0001061 and CL:0001087 and committed/pushed the changes.

Fixed the typos for both CL:0001061 and CL:0001087 and committed/pushed the changes.

Is Travis blocked for lack of funds?

Is Travis blocked for lack of funds?

Unsure of the conflict here, since I added only one class and made fairly small changes to another.

Unsure of the conflict here, since I added only one class and made fairly small changes to another.


Update imagesandcontainers.md

Proposed changes
This PR just removes spaces in imagesandcontainers.md for better read experience.
Here is an example why these spaces are ugly

See: https://deploy-preview-5458--docker-docs.netlify.com/engine/userguide/storagedriver/imagesandcontainers/

@johndmulhausen I think it's better.

Run the docker ps command to verify the 5 containers are running.

this point don't look nice, but there is no possibility to make it nicer

@slawiko Thanks for the reformatting. I don't know if you are aware, but you can scroll long code blocks horizontally. It isn't as nice on mobile, but on a system with a mouse or trackpad it works well.


Input error message width fix

When adding a custom error message to a form input that is longer than the input label, the error message text stacks vertically (see screenshot below). This fixes that by making the label fullwidth when it is active.

After the fix:

Hmm i'm not sure how to reproduce this. We already have a css rule that makes the label 100% width to fix this issue. Do you have an example or issue that you can reference?

This is fixed but not realeasd

Awesome, thanks. You guys are doing a great job with Materialize. Keep up the good work!


Prep for release 0.13

Resolves #3662
Update change log.

/test-force-approve

/test-force-approve


Configuration location under Mac OS is surprising

Hi,
The configuration location under Mac OS X is /Users/.../Library/Preferences/kak-lsp, as returned by dirs::config_dir https://docs.rs/dirs/2.0.2/dirs/fn.config_dir.html whereas Kakoune uses /Users/.../.config/kak.
Technically, kak-lsp is following the OS's convention and Kakoune is violating it, but that's still surprising as a user.
As Kakoune will probably not stop supporting ~/.config, I think kak-lsp should hardcode support with .config/kak-lsp in order to be less surprising to Kakoune users.
Would you be open to accepting such a patch? Otherwise a warning in the README would be appropriate.

this is really painful for me, readme.md just give the wrong doc about the path in macOS. I figured this out by running the source code...

Yes, we should use ~/.config/kak-lsp even on macOS (we can still use the current location as fallback).
Will be a nice to simplify the README a bit.


Secret "org1-msp-crypto" not found

sometimes, we cant create msp-crypto secret
org:

apiVersion: ibp.com/v1beta1
kind: Organization
metadata:
  creationTimestamp: "2023-02-07T07:30:32Z"
  generation: 1
  labels:
    bestchains.organization.admin: org1admin
  name: org1
  resourceVersion: "3240"
  uid: e953a900-3a98-4de3-9a3a-05a6df6b47dd
spec:
  admin: org1admin
  admintoken: eyJhbGciOiJSUzI1NiIsImtpZCI6IjVhNDgwNjc5OWYxNDk4ZTIwZmVjYzZiODFiZTIxNmM3ODU3YTc4ZTAifQ.eyJpc3MiOiJodHRwczovL3BvcnRhbC4xNzIuMjAuMC4zLm5pcC5pby9vaWRjIiwic3ViIjoiQ2dsdmNtY3hZV1J0YVc0U0JtczRjMk55WkEiLCJhdWQiOiJiZmYtY2xpZW50IiwiZXhwIjoxNjc1ODQxNDMwLCJpYXQiOjE2NzU3NTUwMzAsImF0X2hhc2giOiJ6WTh4MmszTTY3a0lwNzBySnpEZFN3IiwiY19oYXNoIjoidHN2bGJEc29UN2VNWUh1eTNKczRaQSIsImVtYWlsIjoib3JnMWFkbWluQHRlbnhjbG91ZC5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiZ3JvdXBzIjpbIm9ic2VydmFiaWxpdHkiLCJzeXN0ZW06bm9kZXMiLCJzeXN0ZW06bWFzdGVycyIsInJlc291cmNlLXJlYWRlciIsImlhbS50ZW54Y2xvdWQuY29tIiwib2JzZXJ2YWJpbGl0eSJdLCJuYW1lIjoib3JnMWFkbWluIiwicHJlZmVycmVkX3VzZXJuYW1lIjoib3JnMWFkbWluIiwicGhvbmUiOiIiLCJ1c2VyaWQiOiJvcmcxYWRtaW4ifQ.GOlHhXP4Tlq8UOUaZSrrmW2uT-Gx-3iZnN3Oo4ydVkg3aaTEOx-C6fJCS9CbR1hFdnRyowWxIML5Qvgi-oj0GArbSVvH7GVb4UVYCAkugp3VyuHwEYWlYqANVJfXopgJzFLpsviaBwR0gdOx3zUf2dtGIpXbiiFI0bI1itI9DOlKYtz2EtGrKpIkBmO2Rxs3W7W4ssWyGVeYQMS79kjieelHcye1MCVnVRAbpwHY1fnao8xy_F_CN3rcPUjBevnb0n6q-HFDfZ_E8iv3YX1ka_ifhUhfpMVdQpjNruBpGW5ZwxxuCcU_W-O-Eg4oeky359KXBmv-b8g8czM51shHhQ
  caSpec:
    action:
      renew: {}
    customNames:
      pvc: {}
    images:
      caImage: hyperledgerk8s/fabric-ca
      caInitImage: hyperledgerk8s/ubi-minimal
      caInitTag: latest
      caTag: iam-20230131
    ingress:
      class: u4a-component-ingress
    license:
      accept: true
    resources:
      ca:
        limits:
          cpu: 100m
          memory: 200M
        requests:
          cpu: 10m
          memory: 10M
      init:
        limits:
          cpu: 100m
          memory: 200M
        requests:
          cpu: 10m
          memory: 10M
    storage:
      ca:
        class: standard
        size: 100M
    version: 1.5.5
  clients:
  - client
  description: test org1
  displayName: test organization
  license:
    accept: true
status:
  federations:
  - name: federation-sample
  lastHeartbeatTime: "2023-02-07T07:32:18Z"
  reason: allPodsDeployed
  status: "True"
  type: Deployed

org1 ca log

Defaulted container "ca" out of: ca, init (init)
2023/02/07 07:31:50 [INFO] Configuration file location: /data/ca/fabric-ca-server-config.yaml
2023/02/07 07:31:50 [INFO] Starting server in home directory: /data/ca
2023/02/07 07:31:50 [INFO] Server Version: 1.5.6
2023/02/07 07:31:50 [INFO] Server Levels: &{Identity:2 Affiliation:1 Certificate:1 Credential:1 RAInfo:1 Nonce:1}
2023/02/07 07:31:50 [INFO] Loading CA from /data/tlsca/fabric-ca-server-config.yaml
2023/02/07 07:31:50 [INFO] The CA key and certificate files already exist
2023/02/07 07:31:50 [INFO] Key file location: /crypto/tlsca/key.pem
2023/02/07 07:31:50 [INFO] Certificate file location: /crypto/tlsca/cert.pem
2023/02/07 07:31:50 [INFO] Successfylly initialized IAM client
2023/02/07 07:31:50 [INFO] Initialized sqlite3 database at /data/db/ca.db
2023/02/07 07:31:50 [INFO] The issuer key was successfully stored. The public key is at: /data/tlsca/IssuerPublicKey, secret key is at: /data/tlsca/msp/keystore/IssuerSecretKey
2023/02/07 07:31:50 [INFO] Idemix issuer revocation public and secret keys were generated for CA 'tlsca'
2023/02/07 07:31:50 [INFO] The revocation key was successfully stored. The public key is at: /data/tlsca/IssuerRevocationPublicKey, private key is at: /data/tlsca/msp/keystore/IssuerRevocationPrivateKey
2023/02/07 07:31:50 [INFO] The CA key and certificate files already exist
2023/02/07 07:31:50 [INFO] Key file location: /crypto/ca/key.pem
2023/02/07 07:31:50 [INFO] Certificate file location: /crypto/ca/cert.pem
2023/02/07 07:31:50 [INFO] Successfylly initialized IAM client
2023/02/07 07:31:50 [INFO] Initialized sqlite3 database at /data/db/ca.db
2023/02/07 07:31:51 [INFO] The issuer key was successfully stored. The public key is at: /data/ca/IssuerPublicKey, secret key is at: /data/ca/msp/keystore/IssuerSecretKey
2023/02/07 07:31:51 [INFO] Idemix issuer revocation public and secret keys were generated for CA 'ca'
2023/02/07 07:31:51 [INFO] The revocation key was successfully stored. The public key is at: /data/ca/IssuerRevocationPublicKey, private key is at: /data/ca/msp/keystore/IssuerRevocationPrivateKey
2023/02/07 07:31:51 [INFO] Home directory for default CA: /data/ca
2023/02/07 07:31:51 [INFO] Operation Server Listening on [::]:9443
2023/02/07 07:31:51 [INFO] Listening on https://<IP_ADDRESS>:7054
2023/02/07 07:34:06 [INFO] <IP_ADDRESS>:36762 GET /cainfo 200 0 "OK"
2023/02/07 07:34:07 [INFO] <IP_ADDRESS>:36764 POST /enroll 401 23 "Failed to get user: can't find user network-sample0 from ids"
2023/02/07 07:34:07 [INFO] <IP_ADDRESS>:36776 GET /cainfo 200 0 "OK"
2023/02/07 07:34:07 [INFO] signed certificate with serial number<PHONE_NUMBER>24121609706368214320515335745393540757
2023/02/07 07:34:07 [INFO] <IP_ADDRESS>:36790 POST /enroll 201 0 "OK"
2023/02/07 07:34:07 [INFO] <IP_ADDRESS>:36798 GET /cainfo 200 0 "OK"
2023/02/07 07:34:07 [INFO] signed certificate with serial number<PHONE_NUMBER>79314692134388958953466075067648725299
2023/02/07 07:34:07 [INFO] <IP_ADDRESS>:36808 POST /enroll 201 0 "OK"
2023/02/07 07:34:08 [INFO] <IP_ADDRESS>:36810 GET /cainfo 200 0 "OK"
2023/02/07 07:34:08 [INFO] signed certificate with serial number<PHONE_NUMBER>16855919178438756163732096712189918741
2023/02/07 07:34:08 [INFO] <IP_ADDRESS>:36818 POST /enroll 201 0 "OK"
2023/02/07 07:34:08 [INFO] <IP_ADDRESS>:36828 GET /cainfo 200 0 "OK"
2023/02/07 07:34:08 [INFO] signed certificate with serial number<PHONE_NUMBER>06841076762610030972607884450956500395
2023/02/07 07:34:08 [INFO] <IP_ADDRESS>:36840 POST /enroll 201 0 "OK"
2023/02/07 07:34:08 [INFO] <IP_ADDRESS>:36848 GET /cainfo 200 0 "OK"
2023/02/07 07:34:08 [INFO] signed certificate with serial number<PHONE_NUMBER>05232582157785200668926221340079658085
2023/02/07 07:34:08 [INFO] <IP_ADDRESS>:36850 POST /enroll 201 0 "OK"
2023/02/07 07:34:08 [INFO] <IP_ADDRESS>:36858 GET /cainfo 200 0 "OK"
2023/02/07 07:34:09 [INFO] signed certificate with serial number<PHONE_NUMBER>47513926909039357645028420094235584116
2023/02/07 07:34:09 [INFO] <IP_ADDRESS>:36874 POST /enroll 201 0 "OK"

operator log
operator-log.log

@Abirdcfly  check ca status. most probably  it took too much time on pulling image

One possible reason is that it took too much time on pulling image.
In local test there may trigger another reason. The pull time of the following image is not too long...
"Successfully pulled image \"hub.tenxcloud.com/u4a-component/bff-server:v0.1.0-20221223\" in 1m8.253531475s"
"Successfully pulled image \"hub.tenxcloud.com/u4a-component/capsule:v0.1.2-20221122\" in 1m26.683960885s"
"Successfully pulled image \"hub.tenxcloud.com/u4a-component/cert-manager-cainjector:v1.8.0\" in 51.586788227s"
"Successfully pulled image \"hub.tenxcloud.com/u4a-component/cert-manager-controller:v1.8.0\" in 1m9.70810772s"
"Successfully pulled image \"hub.tenxcloud.com/u4a-component/cert-manager-webhook:v1.8.0\" in 58.537515016s"
"Successfully pulled image \"hub.tenxcloud.com/u4a-component/iam-provider:v0.1.0-20221223\" in 22.156470994s"
"Successfully pulled image \"hub.tenxcloud.com/u4a-component/ingress-nginx-controller:v1.3.0\" in 1m1.517984838s"
"Successfully pulled image \"hub.tenxcloud.com/u4a-component/kube-oidc-proxy:v0.3.0-20221008\" in 17.411147568s"
"Successfully pulled image \"hub.tenxcloud.com/u4a-component/oidc-server:v0.1.0-20220923\" in 1m6.740135374s"
"Successfully pulled image \"hub.tenxcloud.com/u4a-component/resource-viewer:v0.1.0-20221024\" in 8.324246263s"
"Successfully pulled image \"hyperledgerk8s/fabric-ca:iam-20230131\" in 31.555210343s"
"Successfully pulled image \"hyperledgerk8s/fabric-ca:iam-20230131\" in 32.879149587s"
"Successfully pulled image \"hyperledgerk8s/fabric-ca:iam-20230131\" in 7.424359703s"
"Successfully pulled image \"hyperledgerk8s/fabric-orderer:2.4.7\" in 1.892604297s"
"Successfully pulled image \"hyperledgerk8s/fabric-orderer:2.4.7\" in 18.928304737s"
"Successfully pulled image \"hyperledgerk8s/fabric-orderer:2.4.7\" in 1m31.41861643s"
"Successfully pulled image \"hyperledgerk8s/fabric-orderer:2.4.7\" in 30.371704319s"
"Successfully pulled image \"hyperledgerk8s/grpc-web:latest\" in 1.841436782s"
"Successfully pulled image \"hyperledgerk8s/grpc-web:latest\" in 1.916302883s"
"Successfully pulled image \"hyperledgerk8s/grpc-web:latest\" in 1m15.674570039s"
"Successfully pulled image \"hyperledgerk8s/grpc-web:latest\" in 1m32.13604183s"
"Successfully pulled image \"hyperledgerk8s/iam-provider:fabric\" in 23.055525242s"
"Successfully pulled image \"hyperledgerk8s/ubi-minimal:latest\" in 1.822674163s"
"Successfully pulled image \"hyperledgerk8s/ubi-minimal:latest\" in 1.85105156s"
"Successfully pulled image \"hyperledgerk8s/ubi-minimal:latest\" in 1.880725516s"
"Successfully pulled image \"hyperledgerk8s/ubi-minimal:latest\" in 1.892004186s"
"Successfully pulled image \"hyperledgerk8s/ubi-minimal:latest\" in 28.981166252s"
"Successfully pulled image \"hyperledgerk8s/ubi-minimal:latest\" in 30.921652345s"
"Successfully pulled image \"hyperledgerk8s/ubi-minimal:latest\" in 37.97291039s"


onEachSide

Laravel Version
10.10
PHP Version
8.2.12
Database Driver & Version
No response
Description
I'm having problems with onEachSide. Please help me
my code:

Steps To Reproduce
key . '%')->orWhere('id', $this->key)->paginate(5);
        return view('livewire.search-question', compact('quizzes'));
    }
}

                    @foreach($quizzes as $quiz)

                    @endforeach

                        {{ $quizzes->onEachSide(6)->withQueryString()->links() }}

Hi there,
Thanks for reporting the problem you are encountering, but it looks like this is a question which may be better suited for a support channel. We only use this issue tracker for reporting bugs with the library itself. If you have a question on how to use functionality provided by this repository you can try one of the following channels:

Laracasts Forums
Laravel.io Forums
StackOverflow
Discord
Larachat
IRC

However, this issue will not be locked and everyone is still free to discuss solutions to your problem!
Thanks.


Apply coupon to anonymous cart returns Cart not found

Environment Details

Spartacus: 1.3.x
Browser: Chrome 78

Setup
in Backoffice, enable and publish promotion rule "coupon_code_fixed_discount".
Make sure coupon SUMMER69's validity and redemptions are greater than 0, and not already used.
Steps to Reproduce
Go to spa storefront
Ensure you are not signed in
Add product to cart
Go to Cart page
Enter coupon code and click Apply
Note the error Cart not found and that the coupon does not apply.
Observed Results
Cart not found message banner is shown and the coupon is not added to Cart
Expected Results
Coupon should be applied, giving success message and Cart updated with Coupon and totals recalculated.

This layout issue is another breaking css change that requires adding some styles to the container to address laying out items one after the either (at the start of the component). Created https://github.com/SAP/cloud-commerce-spartacus-storefront/issues/5193 to track this.

I see the fix.
Able to checkout as guest user.


Add Dockerfile to build a Docker image for SDK Doctor

Motivation
Easily run SDK Doctor on any system with Docker installed, without
downloading/installing binaries.  Also, easily run SDK Doctor on a
Kubernetes cluster to test connectivity in situ.
Modifications
Added a Dockerfile to perform build.
Results
Running docker build -t tagname . will build a slim Docker image using
a multi-stage build.
An example build is currently available on Docker Hub at
btburnett3/sdk-doctor.
Usage:
docker run --rm btburnett3/sdk-doctor diagnose couchbase://node/bucket

Kubernetes usage:
kubectl run sdktest --rm -i --image btburnett3/sdk-doctor -- diagnose couchbase://node/bucket

It would be desirable to include this build process in .travis.yml and
publish the image to couchbase/sdk-doctor, but I lack the credentials
so did not include it at this time.

Hey @brantburnett,
Any chance you could contribute an example of the expansion of our travis configuration to build the docker image?
Cheers, Brett

@brett19 sure thing, not too hard.


distrobuilder: add repack-windows dependencies

Description of changes
repack-windows is used to inject Incus device drivers into a Windows ISO for use with Incus.

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 342611 run on x86_64-linux 1

1 package built:

distrobuilder

This actually breaks aarch64 as shown in the tests


Fix npm publish action

@tonyKunchev
To fix
https://github.com/Ontotext-AD/ontotext-platform-custom-scalars/actions/runs/336312384

NPMJS NPM_TOKEN added as Ontotext Github secret.
Need the above change to test..


Add in a working 2.2 SUT for hyperledger fabric

Hopefully now there is a usable fabric-node-sdk 2.2 which means it should now be possible to declare a 2.2 SUT binding.

a 2.2.3 SUT has now been added.


Add support for Confluence 7.1.x

Hi, I really like your plugins. Could you please add support for the latest version of Confluence:
https://confluence.atlassian.com/doc/confluence-7-1-release-notes-976776964.html
Thanks!

in the progress

Done


Use custom components

In some cases, custom components should be used in dashboard panels.
To bring an example, currently the selectors for game winners (no win, A win, B win) are pieced together from their components in the dashboard code. A cleaner solution would be to create a winner-selector custom element that the dashboard code can add to the panel.

Being worked on by 3.2.0.


What about Slack?

I search it many times but I don't find slack on the list! 😐
https://status.slack.com/

They're using their own status service I think, so we'll need to have a custom implementation for it!
I know I used Slack specifically for the marketing video, but I didn't notice it's not really included, so I'm sorry for that..
Will be working on it soon!

@alisalahio Happy to take this now if you like?

That would be awesome! Here's stts implementation, it could help lol
https://github.com/inket/stts/blob/master/stts/Services/Slack.swift

@alisalahio They do in fact have an API and I have it more or less implemented. Just doing some tests before send it across to you.
https://api.slack.com/docs/slack-status

Oh how did you discover this!! Thank you 🔥🔥

@alisalahio I have worked with Slack's API's in the past so know about it from digging around in the documentation.


Use spread operator for named vararg

This was giving the warning 'Assigning single elements to varargs in named form is deprecated.' in IntelliJ IDEA.

The warning could also be solved by swapping the arguments with which the order function is called and not using the products named argument. You can see an example of this solution in the TestShop.kt file (lines 49 and 50). Regardless of the chosen solution, I would recommend keeping the code consistent.

@jarekankowski Although I was aware of both, I chose this solution as this would show a learner an alternative way to call a function with named varargs. It remains to be decided whether this takes precedence over consistency.

aksh1618, thanks for noticing this problem! I've fixed it in a way mentioned by @jarekankowski


RFC Change license of Invenio v3 to MIT license

Proposal
Change Invenio v3 license to MIT license.
Following is a list of repositories affected in inveniosoftware:
BSD-3-Clause -> MIT
inveniosoftware/cernservicexml
inveniosoftware/datacite
inveniosoftware/dojson
inveniosoftware/flask-breadcrumbs
inveniosoftware/flask-celeryext
inveniosoftware/flask-cli
inveniosoftware/flask-iiif
inveniosoftware/flask-menu
inveniosoftware/flask-sitemap
inveniosoftware/flask-sso
inveniosoftware/flask-webpackext
inveniosoftware/idutils
inveniosoftware/jsonresolver
inveniosoftware/pynpm
inveniosoftware/pywebpack
inveniosoftware/requirements-builder
inveniosoftware/xrootdpyfs

GPL-2.0 -> MIT
inveniosoftware/citeproc-py-styles
inveniosoftware/cookiecutter-invenio-module
inveniosoftware/dcxml
inveniosoftware/domapping
inveniosoftware/doschema
inveniosoftware/generator-invenio-js-module
inveniosoftware/invenio
inveniosoftware/invenio-access
inveniosoftware/invenio-accounts
inveniosoftware/invenio-accounts-rest
inveniosoftware/invenio-admin
inveniosoftware/invenio-app
inveniosoftware/invenio-app-ils
inveniosoftware/invenio-archivematica
inveniosoftware/invenio-assets
inveniosoftware/invenio-base
inveniosoftware/invenio-cache
inveniosoftware/invenio-celery
inveniosoftware/invenio-charts-js
inveniosoftware/invenio-circulation
inveniosoftware/invenio-collections
inveniosoftware/invenio-communities
inveniosoftware/invenio-config
inveniosoftware/invenio-csl-rest
inveniosoftware/invenio-db
inveniosoftware/invenio-deposit
inveniosoftware/invenio-files-js
inveniosoftware/invenio-files-processor
inveniosoftware/invenio-files-rest
inveniosoftware/invenio-formatter
inveniosoftware/invenio-github
inveniosoftware/invenio-i18n
inveniosoftware/invenio-indexer
inveniosoftware/invenio-jsonschemas
inveniosoftware/invenio-logging
inveniosoftware/invenio-mail
inveniosoftware/invenio-marc21
inveniosoftware/invenio-memento
inveniosoftware/invenio-migrator
inveniosoftware/invenio-oaiharvester
inveniosoftware/invenio-oaiserver
inveniosoftware/invenio-oauth2server
inveniosoftware/invenio-oauthclient
inveniosoftware/invenio-openaire
inveniosoftware/invenio-opendefinition
inveniosoftware/invenio-orcid
inveniosoftware/invenio-pages
inveniosoftware/invenio-pidrelations
inveniosoftware/invenio-pidstore
inveniosoftware/invenio-previewer
inveniosoftware/invenio-previewer-ispy
inveniosoftware/invenio-query-parser
inveniosoftware/invenio-queues
inveniosoftware/invenio-records
inveniosoftware/invenio-records-files
inveniosoftware/invenio-records-js
inveniosoftware/invenio-records-rest
inveniosoftware/invenio-records-ui
inveniosoftware/invenio-rest
inveniosoftware/invenio-search
inveniosoftware/invenio-search-js
inveniosoftware/invenio-search-ui
inveniosoftware/invenio-sequencegenerator
inveniosoftware/invenio-sipstore
inveniosoftware/invenio-sse
inveniosoftware/invenio-stats
inveniosoftware/invenio-theme
inveniosoftware/invenio-userprofiles
inveniosoftware/invenio-webhooks
inveniosoftware/invenio-xrootd
inveniosoftware/kwalitee
inveniosoftware/metainvenio
inveniosoftware/iugw2017
inveniosoftware/training

Missing license -> MIT
inveniosoftware/invenio-csl-js

Following is a list of affected repositories in inveniosoftware-contrib:
BSD-3-Clause
inveniosoftware-contrib/flask-notifications

GPL-2.0
inveniosoftware-contrib/invenio-checker
inveniosoftware-contrib/invenio-classifier
inveniosoftware-contrib/invenio-groups
inveniosoftware-contrib/invenio-matcher
inveniosoftware-contrib/invenio-metrics
inveniosoftware-contrib/invenio-workflows
inveniosoftware-contrib/invenio-workflows-files
inveniosoftware-contrib/invenio-workflows-ui
inveniosoftware-contrib/json-merger
inveniosoftware-contrib/ng2-json-editor
inveniosoftware-contrib/record-recommender

GPL-3.0
inveniosoftware-contrib/lumberjack
inveniosoftware-contrib/obelix
inveniosoftware-contrib/obelix-client
inveniosoftware-contrib/invenio-record-editor
inveniosoftware-contrib/invenio-tags

Noteably the following repositories are excluded from inveniosoftware and
inveniosoftware-contrib:
inveniosoftware/inveniosoftware.org (AGPL-3.0)
inveniosoftware/claimstore (GPL-3.0)
inveniosoftware/intbitset (LGPL-3.0)
inveniosoftware/dictdiffer (already MIT)
inveniosoftware/flask-security-fork (already MIT)
inveniosoftware/timegate (Revised-BSD)
inveniosoftware-contrib/workflow  (BSD-3-Clause)

Repositories in inveniosoftware-attic will stay with their existing license,
since these are decommissioned repositories.
Why now?

CERN management wants a Contributor License Agreement (CLA) on Invenio (and all other CERN open source projects) so now is a good occasion to review the license situation.
Feasibility: Invenio v3 has a low number of copyright holders which makes it feasible to contact all copyright holders to ask for the agreement.
We have very few GPL dependencies that can be removed.
Invenio v3 have transitioned from a software to a framework which opens up the use of Invenio for many other use-cases than just digital repositories.

In short, we have a chance to change the license now. This chance will no longer exists in 1 year.
What do we want to achieve?
CERN and EU (aka taxpayers) has invested significant efforts in the development of Invenio as the primary contributor to Invenio v3, and CERN therefore wants to maximize the impact of Invenio for the benefit of society. Hence, we are specifically concerned about ensuring Invenio is useful to not only CERN, but also to universities, governments, businesses and people around the world.
We want to achieve that:

Invenio as a framework does not have legal barriers that prevent future unforseen use-cases.
Commercialization of Invenio that will help drive the dissemination and adoption of Invenio.
Bring economic benefits to industry in CERN member states (i.e. public research funding of CERN have an economic and social impact on CERN member states).

Note specifically, that with the license change we do not want to achieve that more people contribute back to the Invenio source code. However, we believe that a derived effect of a license change will drive an increased adoption of Invenio which will result in increased contributions back to the Invenio source code.
Why not GPL?
GPL is a viral license, meaning that anything else combined with Invenio becomes GPL automatically. This also means that with GPL we have no option for later switching license, and hence GPL can become a legal time-bomb which prevents later commercialization and future use cases of Invenio. This legal time-bomb could be mitigated by transferring the completely copyright of Invenio to CERN, but that involves a lot of bureaucratic and administrative work on both contributors and maintainers. Also, since Invenio is now a framework, we believe that we are yet to see many new uses of Invenio, even way beyond digital repositories. Specifically GPL prevents developing modules to Invenio which can be kept private.
Often GPL is used to force source code contribution to a product. First of all, this is not a objective we want to achieve with the license change, however  for Invenio, so far GPL has not a single time been used to force anyone to contribute to Invenio. We believe people contribute to Invenio because they realize a greater value by contributing than if kept private.
Why not Apache v2
The main benefit of Apache v2 is the grant of patent rights. This problem will be handled by a contributor license agreement that all non-CERN contributors will have to sign which will ensure patent rights. Also the license text is much longer than BSD/MIT.
Revised BSD or MIT
Both are very permissive licenses. MIT is the most widely adopted license with some 25-30% of the open source projects using it with BSD at around 5-10%. Revised BSD license explicitly forbids using our names in promotional material without written permission (but this is anyway implicit in MIT). Revised BSD uses words like "use and redistribution" where as MIT is more specific to also mention "use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies"
Who finally decides?
As always we strive for consensus decisions on important topics like this, however in the end it is the existing copyright holders of each repository who have the final say.
CERN commitment to Invenio
CERN is still fully committed to continuing Invenio development.
Externally developed Invenio modules
The proposal is limited to Invenio v3 and direct dependencies. Specifically, anyone can make an Invenio module and license it under whichever license they like (given they hold the copyright). We will however only include Invenio modules in our GitHub organisation which is aligned with our default chosen license. Hence, if you release an Invenio modules under GPL, you will need to host it in your own organisation.
Note that CERN services like CDS, Zenodo and CERN Open Data remains under GPL.
Timeline
October 9th: Discussion in Invenio Developer Forum
October 16th: Proposal to CERN IT management to change license.
October/November: Contact existing copyright holders to get agreement for license change.
November: Implement license change

for Invenio, so far GPL has not a single time been used to force anyone to contribute to Invenio

In fact, a company has used a known loophole in GPLv2 to not contribute, which is why I instead propose to switch to AGPLv3, so that those interested non-contributing developers will not be able to pull this off in the future. In my world view, non-cooperation from someone is answered with non-cooperation from my side, not even more cooperation1.
Moreover, I don't buy your argument that this is good for Invenio. The past suggests that companies selling Invenio are not going to contribute back. The libraries and the universities that are going to buy services from those companies are not going to contribute back: not having to write code is why they bought the services in the first place. You're claiming that, if those companies are successful, people visiting these services will learn about Invenio, which might lead to more people contributing to core packages. Maybe, but in order to get those eyeballs you let a company earn (m|b)illions. Perhaps a few hundred dollars in targeted ads on your favorite platform is a more cost-effective option?
Finally, sorry, but Invenio will never be as big as Flask or Django. It aims to solve a fairly narrow problem, of which there's some need for a solution in the world, but not a lot of it. Most people that have ever contributed to Invenio were paid to do so, and I expect this to continue being true in the future.
1 See: http://ncase.me/trust/

Forwarded this proposal to join2 / join2 steering for evaluation in our project.
The proposed timeline is quite tough to meet, if one wants any comments at all.

In fact, a company has used a known loophole in GPLv2 to not contribute, which is why I instead propose to switch to AGPLv3, so that those interested non-contributing developers will not be able to pull this off in the future.

I must say that indeed contributing back to Invenio 1 was quite complicated and that could explain why a company basing its product back in the days was having difficult to contribute back (one was forced to hack business logic deep into the core of Invenio and this could have been problematic to share). Invenio 3 is instead extremely modular, and indeed it's very clear how one could contribute back to a specific module. A company based on Invenio 3 could have its core business in internal components that don't need to be contributed upstream, while it wouldn't cost anything to simply keep public forks of those Invenio component that are employed in once project, since these will very likely not contain any sensible private business logic or secret value of the company.

@aw-bib Unfortunately the timeline is quite tight because until the issue is resolved, all merging of non-CERN contributions are on hold (as incase we decide to go ahead, we need to ask all copyright holders for permission). Also, I'm open to pull the break in case further discussion is necessary, but I prefer a short, intense and focused discussion.
I'd like to hear both more comments/opinions/arguments for or against the proposal.

@lnielsen I see your point, however, for a response from join2 we need to ask the members. Getting several insitutions(!) into one (even virtual) room is a bit more challenging than just shouting over the floor ;) However, I put your RFC with important markers on the agenda right away and hope to discuss it in our weekly.

@aw-bib I understand your concern, so your effort in putting it high on the agenda is very much appreciated. I'd be interested to know if join2 or the institutions in join2 have an official open source software license policy, and/or if changing from GPL to a permissive license would prevent you from contributing.

I must say that indeed contributing back to Invenio 1 was quite complicated and that could explain why a company basing its product back in the days was having difficult to contribute back

In general I tend not to like the argument "it was hard!" to justify why something was not done, but in particular a representative of this company explicitly said at a meeting with all the developers of all Invenio projects at CERN that they were using the GPLv2 ASP loophole.

Purpose
Thanks for the comments so far. Let me just reiterate why we want to change the license:

Library: Invenio has been transformed from a software application into a library that you can mix/match as you see fit. Most libraries in the world are released under a permissive license (LGPL, Apache, BSD, MIT, ...) to not impose a license on downstream applications. Take e.g. Invenio where we only had one GPL dependency out of our ~200 dependencies. Having a permissive license for Invenio makes it easier to combine with other applications and makes it easier to adopt. Also, having a permissive license, doesn't prevent further downstream product to be GPL (e.g. we don't currently plan to change license of Zenodo, CDS etc from GPL).
Commercialization: We want to allow companies and institutions to keep their add-ons private if they so desire (and forks for that sake). More than halfs of CERNs funding (tax payer money) is going back via e.g. procurement to member states to generate economic benefits and competencies in companies in the member states. This is an explicit desire from our member states, that money invested in research at CERN goes back out into society. Having a permissive license ensures more possibilities for commercial exploitation.

Source code contributions
Note that I specifically mention in the proposal that the the purpose of the license change is NOT aimed at increasing source code contributions to Invenio.
We can debate, whether or not increased source code contributions would be a derived effect of a license change, however again, that's not why we want to change the license. Increased source code contributions as a lot more to do with an open community where people see the benefit of contributing than the license. Also, note that we already have an existing project on making contribution easier. But again, this is not the purpose of the license change.
Impact outside CERN?

To state the obvious: I guess of course you meant, from GPL to MIT.

On behalf of the JOIN2 Steering Group:
First of all, non of the institutions within JOIN2 have any policy that prevents them from using non-GPL software or to contribute to projects with free, but non-GPL licences. So there is no formal issue from JOIN2 against a change in license.
However, the JOIN2 community believes that the envisioned change in the Invenio licensing scheme does not help to achieve the goals brought forward.  Especially, JOIN2 does not see how a change away from GPL addresses

maximize the impact of Invenio for the benefit of society.

JOIN2 does also not share the opinion that

a license change will drive an increased adoption of Invenio

The JOIN2 community believes, that adoption of Invenio is not hindered by using GPL as a licence, while JOIN2 believes that one can expect some cooperation, even from companies, who use for free what was achieved by

CERN and EU (aka taxpayers) has invested significant efforts

JOIN2 want to stress that we especially like the fact that GPL is a viral license and this ensures that everyone (even the taxpayer) can profit from improvements. (In this regard JOIN2 even sympathizes with @jacquerie comment.) JOIN2 sees no real issues with GPL even for extensions around Invenio or businesses build on top of Invenio. JOIN2 is of the opinion that one can build viable business models on GPL software.

We believe people contribute to Invenio because they realize a greater value by contributing than if kept private.

JOIN2 makes the point, that if this is the case there is no need to change the license at all. One can stay with GPL and also to make the clear political statement that contributions back to the project are welcome.
JOIN2 can envision, however, some sort of dual licensing as common in other projects, if ever a need for another license than GPL arises.

Alternatively, have you considered LGPL? With that license, modifications to core invenio would need to be open and benefit all of the invenio ecosystem, but a business model could be built around developing and selling closed source extensions.

Though personally I think that AGPL is the best way to go in the long run (ecosystem wise), and that you can still build a business around it, just not by hiding code (you can still sell it, just that you have to give the source code too), I understand that lots of people don't see it that way, and are afraid of using a "really free" license, so maybe LGPL is good enough, at least, that way they will have to publish any changes that they make to the core, then the community can decide if they should be integrated or not.
Just my two cents.

For today's DevForum discussions, I've compiled a draft list of copyright holders for the inveniosoftware repositories. I've only included repositories which are currently under GPL.
Following repositories have CERN as the sole copyright holder:
inveniosoftware/citeproc-py-styles
inveniosoftware/dcxml
inveniosoftware/doschema
inveniosoftware/generator-invenio-js-module
inveniosoftware/invenio-access
inveniosoftware/invenio-assets
inveniosoftware/invenio-accounts
inveniosoftware/invenio-accounts-rest
inveniosoftware/invenio-admin
inveniosoftware/invenio-app
inveniosoftware/invenio-app-ils
inveniosoftware/invenio-archivematica
inveniosoftware/invenio-base
inveniosoftware/invenio-cache
inveniosoftware/invenio-celery
inveniosoftware/invenio-charts-js
inveniosoftware/invenio-circulation
inveniosoftware/invenio-collections
inveniosoftware/invenio-config
inveniosoftware/invenio-csl-rest
inveniosoftware/invenio-db
inveniosoftware/invenio-deposit
inveniosoftware/invenio-files-js
inveniosoftware/invenio-formatter
inveniosoftware/invenio-logging
inveniosoftware/invenio-marc21
inveniosoftware/invenio-migrator
inveniosoftware/invenio-oaiharvester
inveniosoftware/invenio-oauth2server
inveniosoftware/invenio-oauthclient
inveniosoftware/invenio-openaire
inveniosoftware/invenio-opendefinition
inveniosoftware/invenio-orcid
inveniosoftware/invenio-pages
inveniosoftware/invenio-pidrelations
inveniosoftware/invenio-pidstore
inveniosoftware/invenio-query-parser
inveniosoftware/invenio-queues
inveniosoftware/invenio-records-files
inveniosoftware/invenio-records-js
inveniosoftware/invenio-records-ui
inveniosoftware/invenio-records
inveniosoftware/invenio-rest
inveniosoftware/invenio-search
inveniosoftware/invenio-search-js
inveniosoftware/invenio-search-ui
inveniosoftware/invenio-sequencegenerator
inveniosoftware/invenio-sipstore
inveniosoftware/invenio-sse
inveniosoftware/invenio-stats
inveniosoftware/invenio-theme
inveniosoftware/invenio-webhooks
inveniosoftware/invenio-xrootd
inveniosoftware/iugw2017
inveniosoftware/metainvenio
inveniosoftware/training

Following repositories have multiple copyright holders:
inveniosoftware/cookiecutter-invenio-module
    CERN, TIND
inveniosoftware/domapping
    CERN, TIND
inveniosoftware/invenio-communities
    CERN, jainaman224
inveniosoftware/invenio-files-processor
    CERN, xiaom
inveniosoftware/invenio-files-rest
    CERN, University of Tubingen
inveniosoftware/invenio-github
    CERN, TIND, kapadia, dan-blanchard, cglewis
inveniosoftware/invenio-i18n
    CERN, TIND
inveniosoftware/invenio-indexer
    CERN, TIND
inveniosoftware/invenio-jsonschemas
    CERN, sulami
inveniosoftware/invenio-mail
    CERN, TIND
inveniosoftware/invenio-memento:
    CERN, cg-cnu?
inveniosoftware/invenio-oaiserver:
    CERN, TIND, University of Tubingen
inveniosoftware/invenio-previewer:
    CERN, targos, jainaman224
inveniosoftware/invenio-previewer-ispy:
    CERN, tpmccauley
inveniosoftware/invenio-records-rest
    CERN, RERO, TIND, satwikkansal
inveniosoftware/invenio-userprofiles
    CERN, guptavaibhav18197
inveniosoftware/invenio
    CERN, TIND, Adam Lawrence, Ivan Masár, João Gonçalves, Xiao Meng, evelthon

Note that this is a draft list and may contain errors.

As a long-time OSS champion at CERN and a member of the task force which penned the original recommendation for CERN to adopt a default GPL policy, I too once believed that GPL and dual licencing was the answer. However experience over the past year of putting this into practice has exposed me to the complications and pitfalls, and I am no longer convinced it is the best way. Firstly, to dual licence you must have unanimous agreement of the copyright holders. The more holders, the less likely, easiest with a unique copyright holder; but copyright transfer was never cleanly established in v1, and isn't the norm in the world, quite the opposite. Secondly you don't dual licence to a permissive version, you dual licence to a completely closed one dedicated to the purpose, and what you define the "purpose" to be is complicated both legally and philosophically. Hence instead, to establish from the start a permissive licence for v3, without copyright transfer as it is unnecessary and undesired, that is just as encouraging of OSS contributions but in addition does not exclude or discourage commercial usage, is a more natural fit. It also aligns us with the majority of real-world packages that we ourselves rely on, and the OSS based business models that we see.

As an extremely minor contributor, I'm neutral towards the change. Feel free to let me know when there's something to agree to or the CLA to sign.

If I can give my 2 cents, I have the feeling that the GPL choice (as Tim Smith also expressed) was the right choice a few years ago, when the culture around open source and sharing was really different, when the web was much less invaded by web projects/frameworks and when big companies feared open source.
In my humble opinion, nowadays, the culture around open source projects has changed: with this "rush" to release software as open source, that hit a very large part of companies that are working with the web, it becomes natural, the way to do, to people to contribute back, and not the contrary. If it was not the case, GPL would have been chosen by most of the projects, wouldn't it? https://www.whitesourcesoftware.com/whitesource-blog/open-source-software-licenses-trends/
A very similar topic is discussed here, when Meteor js long time ago (5 years ago!!!) decided to change license from GPL to MIT, and in the infinite discussion on HackerNews, a couple of comments can, in my opinion, summarize and maybe help to understand the choice of CERN/Invenio:
GPL restricts the pool of potential collaborators.

Also, GPL has served its purpose: these days 1) almost everyone realizes that it is in
everyone's interest to share code and contribute back (maintaining private forks is
expensive in the long term), and 2) most software is offered as a service and the value
is not just in the software, but also in the infrastructure, maintenance, support, etc,
meaning you rarely encounter the problem of restricted liberties because of a
software license.

GPL requires you to give back; MIT gives you the choice. Developers are by nature creative
people. And humans are not incapable of altruism. Even with an MIT license, I expect
a lot of community contributions to pour in.

In fact, I expect more community contributions to come in. MIT means (perhaps) a lower
percentage of users will give back, but there will be a higher absolute number of users
since the license is more permissive.

Just my personal opinion (not join2, not my employer or whoever).
IMHO the reasoning against GPL is a logical circle. So far the reasoning is

We needed GPL back then because companies feared Open Source.
Nowadays, companies live in Open Source and release everything in Open Source anyway. There was a change in culture and a rush to release. (Only slightly exaggerating the points made, just for clarification.)
Because companies live in Open Source, one needs a "more permissive" license and not something viral like GPL.
That is required, because companies need the possibility to hide back something to rise their share holders value.

This is contradictory.
If a company really lives in Open Source (A)GPL would not hinder them in anything. They'd release all their stuff anyway, and if we see a change in culture (A)GPL would be a natural thing to them. It would also ensure that the competitor does the same. If we do not see the change in culture we should head for it, again we are at (A)GPL.
Companies only need something "more permissive" if they do not want to share everything. To keep something private to be "better", to "raise their corporate value". (This is also in line put forward by @lnielsen in Dev Forum.) I buy this point as a reason, but I do not support it.
At some point it IMHO boils down to the question what I buy from a company.  In Open Source I would not buy software, but I would probably buy the hosting and other services around it. So it is unimportant that the software is really open or not. I'd even go so far as to say that the software as such is entirely unimportant and interchangeable in this framework as long as the service stays the same. Hypothetically, Open Source would give me as a customer the advantage of the vague possibility to switch my service provider, so I could argue that this is an advantage for a business running on Open Source software.
Furthermore, where I usually lack openness is when it comes down to interfaces. Naturally, the interface definition has to live within the code where I need this interface. At least this definition has to be free to ensure that I could live on an interface even if a company just looses interest in supporting anything on it. (Here I could follow @david-caro argument for LGPL, or more generally non-AGPL, as a minimal requirement.) Much of the hackish stuff I need to do (I'd not call this "development") is exactly fixing such issue, working around it, up to the point of reverse engineering some strange protocol or format.
Given software being interchangeable, but interfaces are not, while I also run more and more on services that communicate with one another via interfaces, IMHO today GPL is required even more than ever to ensure that free software stays free and usable.
To me, as a tax payer, the latter is also of foremost importance. Just if one wants to make a monetary point.
The more natural reasoning is that you are of course free to swing your fists.  But this freedom ends at the tip of my nose. So what you call restriction of freedom may just be ensuring its persistence.

Seeing how the licensing discussion evolves, I sense a certain split in the
community that makes me feel uneasy. Having steered Invenio project for about
fifteen years, I would like to bring some late-night musings on this touchy
topic. I hope my reflections might be useful in bridging the two perspectives.
Everybody is entitled to their opinions, and discussions about licensing are
usually very opinionated. Here's hope that my musings won't add even more fuel
to the fire.
TL;DR One can argue that (1) with GPL, the community has lower potential for
growth, since there are some public users (and most private companies) that
would refrain from entering that territory; however the final product is
guaranteed to remain free software for the community. While (2) with
LPGL/BSD/MIT, the community has higher potential for growth, which can improve
the product; however at a risk that the non-free software in the ecosystem might
take larger and larger share, perturbing the hitherto free ecosystem. The
decision is a judgement call, the outlook is uncertain, the opinions of software
creators and of free software advocates will likely differ. Seeing some opinions
going predominantly in one or the other direction, it is important to try to
consider the perspectives with a balanced point of view, to ponder not only the
pros but also the cons and vice versa, to reflect on the strategical
implications of mixing free and non-free components and how it might affect
certain use cases in our ecosystem more than others. Finally, it would help to
better clarify the motives behind the move, because a sentence like "Note
specifically, that with the license change we do not want to achieve that more
people contribute back to the Invenio source code" might look really puzzling.
Nicola rightly highlights that the times have changed since the days of old
(e.g. Microsoft is now amongst the top open source code contributors on GitHub;
who would have thought?) and that the permissive licenses such as MIT have been
gaining momentum in recent years thanks to amongst others the web development
technologies. However, note that GPL remains the most popular license choice out
there; the very quoted article permits to conclude that GPL remains at the top
with 34% market share (19% for GPLv3 and 15% for GPLv2) over 25% for MIT. (The
article itself says so later on, even if their choice of introductory picture
was to present the findings otherwise, with MIT on top over GPLv3. In my eyes,
when one compares the market share of web browsers, one should be comparing the
overall impact of say Firefox and Chrome, not studying Firefox 54 and Firefox 56
apart.)
Nicola also rightly highlights that the companies have very good incentives to
contribute to some of the free-software components they use. However, this is
only one part of the picture. The companies also have very good incentives not
to contribute those components where they perceive their competitive advantage,
making them non-free and closed-source. A possibility to mix free, open-source
components with non-free, closed-source components is precisely the at the core
of LGPL/BSD/MIT existence.
From the point of view of a software creator, let me borrow the above quote to
illustrate the core of the thinking:
MIT means (perhaps) a lower percentage of users will give back, but there will
be a higher absolute number of users since the license is more permissive.

This is exactly the heart of the matter and I think the word "perhaps" is the
key here. It cannot be easily foretold what such a license change brings; it
could foster the free-software part of the ecosystem, just as it could foster
the non-free-software part of the ecosystem. One only speaks of probabilities
here.
From the point of view of a free software activist, the same "perhaps" appears.
Let me borrow the GNU/FSF musings on why it is sometimes bad and sometimes good
to use LGPL over GPL:
Using the Lesser GPL for any particular library constitutes a retreat for
free software. It means we partially abandon the attempt to defend the users'
freedom, and some of the requirements to share what is built on top of
GPL-covered software. In themselves, those are changes for the worse.

Sometimes a localized retreat is a good strategy. Sometimes, using the
LGPL for a library might lead to wider use of that library, and thus to more
improvement for it, wider support for free software, and so on. This could be
good for free software if it happens to a large extent. But how much will
this happen? We can only speculate.

It would be nice to try out the LGPL on each library for a while, see
whether it helps, and change back to the GPL if the LGPL didn't help.
But this is not feasible. Once we use the LGPL for a particular library,
changing back would be difficult.

So we decide which license to use for each library on a case-by-case basis.

I think this summarises nicely the feeling of a free software activist as well.
The licence change from GPL to LGPL/BSD/MIT is basically a "gamble" that the
change will help to increase the user base of the free-software ecosystem, even
at the price of inviting non-free components, and that this change will overall
benefit the original free-software community. However, it is a decision that is
fully speculative, and to be pondered rather carefully.
Historically, Invenio has been using GPL from its inception in 2002. It has been
developed mostly at CERN for the purpose of running various particle physics
services. It has been adopted since 2002 already by various organisations,
institutes and libraries both small and large. The adopters were usually not
bothered by the GPL license; in fact, the GPL license was typically considered a
big plus, because the licence gave a moral ground that any improvements will be
shared within the ecosystem for the mutual benefit. When there was a good reason
to change the license later, such as for intbitset library (moved from GPL to
LPGL at the demand of an Apache project), or for Flask-* extensions (moved
from GPL to BSD that the Flask ecosystem natively uses), the proposed change was
always approved by the respective CERN and non-CERN code contributors. It was a
painful work to change the license, and this energy could have been devoted
elsewhere; but the potential benefits were considered worth the trouble, and we
did see minor code contributions coming after this change.
Enter 2017. Widening the license change from GPL to LGPL/BSD/MIT upon all
Invenio components may be seen as a rather categorical move. On one hand, it is
a logical continuation of the Flask-* licensing changes mentioned above (and
one could argue that the logical licence choice would be BSD for us). This is
especially true for our "base" technology components. Invenio can be seen as a
configurable Flask application builder helper, so to speak, usable for any Flask
application outside of the strict digital library domain. (RECAST's need for
OAuth comes to mind.) However, on the other hand, and especially for our
"add-on" components, it can be questioned whether say Circulation is truly of
"library" nature, and not rather a complete "app" that services would usually
develop on top of the said libraries in their overlays? Be it as it may, there
is also a certain beauty and practical advantage behind using the same license
for all Invenio components.
A possibility that the "circulation app" may be likely open-source, if developed
by a public institution, and likely closed-source, if developed by a company, is
something that the licence change from GPL to LGPL/BSD/MIT would encourage, as
it were, since the "moral imperative" to share associated with GPL would not
longer apply. This brings an inevitable question of how the ecosystem of mixed
free and non-free components might look like in the future.
Let us imagine that somebody started to use Invenio because they liked a
particular feature set, e.g. support for a particular data format (MARC) or a
particular digital repository flavour (multimedia management) or a particular
add-on application (keyword tagging). Imagine that such a feature is a mandatory
must-have to some members of the ecosystem, while an optional nice-to-have to
other members of the ecosystem. Now imagine the original developers stop
supporting the given feature set for a reason or another, for example the
business priorities change, the funding models change. The hitherto maintained
feature set is now at a risk of no longer being maintained. How is this
situation handled under different licensing scenarios? With GPL, one can always
take up the original code, but the members of the ecosystem must find resources
to take up its maintenance. An optimist might argue that if the community has
grown sufficiently large, then there will be opportunities to take it up. A
pessimist might argue that funding in our domain goes smaller and smaller, so
that this would be a problem, and people might have to move elsewhere. With
LGPL/BSD/MIT, the commercial players can enter the game and offer their
services. An optimist might argue that it is great that the commercial providers
can fill the hole, and that the free market competition will ensure the
reasonable pricing at the end. A pessimist might argue that the commercial
vendors will try to lock their users up to their clouds, and aim at
Elsevier-style profits. I am exaggerating, obviously. The point is, nobody
knows. The glass can be both half-full and half-empty, and people are likely to
disagree about the probabilities of those optimistic and pessimistic scenarios,
based on their personal outlook, the past experiences, and the knowledge of our
concrete ecosystem.
In any case, the arrival of non-free software components into a hitherto
essentially free-software ecosystem will create an imbalance, where some use
case applications and components might thrive thanks to the increased overall
usage, while other use case applications and components might struggle or might
become the domain of the non-free in longer term. That's the example of a
dilemma of the free software activist applied in our particular domain.
The choice of a more permissive license is basically an expression of trust that
the overall benefits will be worth it in the longer-term. From a software
creator point of view, the likelihood looks good. From a free software advocate
point of view, the opinions will likely differ, as will the assessment of
dangers for each concrete beloved feature set of our current ecosystem.
It is up to us, the Invenio community, to try to set the rules so as to maximise
the opportunities and minimise the risks. Building a healthy cooperating
ecosystem may be more important than the concrete license choice. History have
seen GPL, BSD, and MIT communities both thrive and struggle. Even GNU Affero GPL
cannot guarantee any shield from the hard case scenarios outlined above, when
projects are impacted by hard real-world events. A good recent example might be
the acquisition of ShareLaTeX (free software, open source, AGPL licensed) by
Overleaf (non-free, closed-source). People who build their future around
ShareLaTeX now face the same hard questions I raised above.
The LGPL might be a better middle-ground choice thanks to our GPL past; the BSD
might be the most logical choice to align to the upstream Flask ecosystem; the
MIT might be the most second-popular choice (after GPL!) out there. Whatever
license we choose, we should quickly start pondering about how to improve the
ecosystem practices, so that the pros would really outweigh the cons, and not
the vice versa.

@tiborsimko I buy all your reasoning especially that it is a gamble.
I would still argue, that, if the main goal is to increase the number of installations the license (given the ones mentioned) is not of that much importance. One would surely have a much larger impact with regard to this, if invenio would "just" be packaged in standard distributions and run on the usual server suspects in some flavour where I can see what it can do, without requiring programmers to set it up.

it is great that the commercial providers can fill the hole, and that the free market competition will ensure the reasonable pricing at the end

I am not sure that a market exists in the domain in question at all. If it exists, it's most likely an oligopolistic (if not even a monopolistic) market. So it is hard for me to buy reasoning based on competition, marked, free forces etc.
OTOH I still do not see anything that hinders integration of some closed source services with a GPL framework provided you contribute the interface. In this case, if the market looses interest, one could at least replace the missing part, as you say by finding the resources to do so.

First of all, I'd like to thank everybody for participating in the discussion and for providing a lot of valuable feedback, and especially also for accommodating the very short timeline.
Open Source license discussions, especially permissive vs copyleft, have the potential to ignite very strong feelings, as the discussion often boils down to strong differences in ideological beliefs. Hence, I'd like to also say thank you for keeping an open, considerate and respectful discussion. I believe it is highly important for a community and a healthy sign to be able to have these hard discussions with strong disagreements in an orderly fashion so that we can continue together afterwards.
I acknowledge that there are strong differences in opinions on this proposal, both outside but also inside CERN's Invenio community. I believe those strong differences boil down to above-mentioned differences in ideological beliefs. In both cases, i.e. adopting the proposal or staying with GPL, it will be a gamble where we can only speculate about the possible outcomes.
I've noted that the proposal will not have a direct negative impact on the existing community, in the sense that users already using Invenio can continue using Invenio, contributors already contributing to Invenio can continue to contribute. Long-term impact, as mentioned before, we can only speculate about, and there are pros and cons no matter which license we adopt.
I believe that due to the ideological differences it will not be possible to arrive at a consensus decision on the proposal, even if we let the discussion run for another month or two. Also, as already mentioned in the proposal, the final decision is taken by the existing copyright holders, as these are the legal owners of the code and the ones that legally have to agree to license change.
In that respect, CERN is the majority copyright holder of Invenio v3 having contributed more than 95+ % of Invenio v3 source code so far. The current situation with GPL plus shared copyright between potentially 100s of contributors is something that CERN believes is an unacceptable legal time-bomb because downstream it will be impossible to revert this decision. Even if the entire community later agreed to go with another license, a single contributor could veto against that decision. Having invested large efforts in Invenio, this is a risk CERN is not willing to take. Hence, we must take a conscious decision now, while we still have a choice.
We (CERN)[1] believe going with a permissive license like MIT is the right choice for Invenio for the reasons we have listed in the proposal and reasons given during the discussions. We believe an alternative, e.g. GPL with copyright transfer to CERN, would have a negative impact on contributing to Invenio as well as be very hard to administrate.
Therefore, considering that a consensus decision will not be possible, considering that a decision must be taken before it is too late, considering that CERN is the majority copyright holder and cannot accept the current license/copyright situation, and considering that the proposal will have no direct negative impact on using or contributing to Invenio for the existing community, I (as Invenio Product Manager) decide to continue with the proposal of changing the Invenio v3 license to MIT license. I take this decision only because I believe a consensus decision cannot be reached on the proposal, and thus I also fully understand that part of our community do not agree with the proposal. I am therefore also happy to take criticism, both public and private, and further discuss the decision, but I do believe I've tried to take a balanced decision.
The final decision still rests with the existing copyright holders, whom I will now take contact to get a legally binding confirmation that they agree to the license change.
Last but not least, I'd like to highlight what Tibor said:

building a healthy cooperating ecosystem may be more important than the concrete license choice

I fully agree with this statement, and I'm fully committed to building that ecosystem in collaboration with all of you.

[1] "We (CERN)" should be understood as CERN's official opinion on the matter as decided by CERN management. I fully acknowledge that some Invenio developers at CERN do not share this opinion.

Specifically GPL prevents developing modules to Invenio which can be kept private.

This is incorrect, as written. See FAQ:

The GPL does not require you to release your modified version. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.

https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#GPLRequireSourcePostedPublic

You are right, the correct sentence should be:
"Specifically, GPL prevents developing modules to Invenio which can be kept private >> and be distributed <<."

Thanks! That's right.


A11y testing and support

The Strimzi-ui should be fully accessible (a11y) from day 0. This issue is to investigate what tooling we can use to catch a11y issues early/make sure the UI is accessible to any user of it.
As per the proposal (https://github.com/strimzi/proposals/pull/6), we will target the superset of US Section 508 and WCAG21AA rulesets.

https://www.npmjs.com/package/cypress-accessibility-checker (if not already aware)


implement please Serializable interface in optimizer package

hi!
I want to distrubute the optimizers (especially the LevenbergMarquardt) to different nodes in my hazelcast cluster. Therefore I would like to ask you if you could implement the Serializable interface to your optimizers.
Thanks and all the best
KIC

Done. I also improved the handling of NaN in values in setValues: NaN is interpreted as "reject parameter". - Please have a look.

cool thanks! For the moment I am not running into NaN's, but I will see what happens :-)


Email notification for when one of the copayers is recovered from a backup seed

I use a 2 of 4 wallet. This means that as long as no more than 1 of my backups is found, nobody else can spend my money. But if just one of my backups is found, someone could recover it an see my wallet without me knowing. I think it would be good if all copayers could got an email notification whenever any of the copayers is restored from a backup seed.

But wouldn't this give a false sense of security since an attacker could use the backup data to see your wallet without contacting BWS?

Also consider the case ownership of the wallet is shared. It could be not
convenient to notify some users about others actions.
On Sat, Jan 16, 2016 at 1:22 PM Ivan Socolsky<EMAIL_ADDRESS>wrote:

But wouldn't this give a false sense of security since an attacker could
use the backup data to see your wallet without contacting BWS?
—
Reply to this email directly or view it on GitHub
https://github.com/bitpay/bitcore-wallet-service/issues/440#issuecomment-172220644
.

Sorry, I meant the word seed. They can't see anything unless they have all the extended public keys, which BWS provides in exchange for the seed, if I'm not mistaken.
@matiu what about just notifying that copayer? Or would the attacker be able to change the email address before? I guess not.


consistent parameter passing for html and latex-generated pdf

@hcolclou and I have pushed a new sphinx theme that implements some CSS3 page media formatting for myst_nb:
https://github.com/eoas-ubc/paged_html_theme#pagedjs-html-sphinx-theme
We'll be using it to provide parts of the functionality of the  latex geometry, fancyhdrs, Lastpage packages as well as an explicit pagebreak.
@choldgraf and @chrisjsewell -- any thoughts on the best way  to pass mulitple parameters like margin/header sizes/content so that the same format works for both latex and chrome-pdf builders?  Tagging @racooneer since it's related to https://github.com/executablebooks/jupyter-book/issues/653

this is an important issue. thanks for opening @phaustin. I think the best approach (but time consuming) is to start building a spec of the parameters that we want to start supporting with a column for myst option -> desired html, pdfhtml and pdflatex output.
This will allow the different teams to work to a single spec and reserve option names when implementing support for the metadata that has been specified in myst in a consistent manner?
Alternatively we could setup an issue template for myst option and I can sync those across to a document for reference. My only hesitation is some options are discussed in myst-parser  and others in myst-nb and others in jupyter-book.
Not sure where to put this (@choldgraf)? -- should we have a myst-specification repo? I was thinking the docs for myst-parser given it holds much of the myst specification - but not always obvious for others to review. It needs to be in a place everyone can refer to and is easily accessible / editable.

I think it's worth having a spec. Right now the myst-parser serves as a reference implementation but I don't know that we have a really clear pattern others can follow for expected behavior.


Output emptyarrays 5167 v2

cf https://github.com/OISF/suricata/pull/7604
Replaces #871 with better jq

Can you rebase this to see if the breakage on 5/6 are fixed? If not, can you look into that?
Took the commit updating bug-130 in #894

Replaced by https://github.com/OISF/suricata-verify/pull/897


Design standard cache management package

As we work to improve Mixer performance, we will be introducing a number of caches throughout. We need a centralized & uniform infrastructure for managing these caches. We need an infrastructure where we can control the total size of each cache, the TTL of entries, the automatic collection of metrics to gauge cache efficiency, etc.
Before coding something custom, we should see if such generic cache management infrastructure already exist out there somewhere.

Done.

There's a new package for this.


[Bug] Fix the Custom Strings with format Args

Purpose

...

Does this introduce a breaking change?

[ ] Yes
[x] No

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

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

Test the code

Launch the call composite with JavaLauncher
Check Call with String

What to Check
Verify that the following are valid

...

Other Information

After

Closed because we won't introduce custom string API.


Vehiclebody3D sliding down slope when parked

Tested versions

Tested in 4.2.1 stable

System information
Windows 10 - Godot 4.2.1 stable - compatibility
Issue description
A Vehiclebody3D parked sideways on a slope will slide down. Depending on gravity, friction, roll influence and spring settings it will slide more or less but it will never stand still unless the gravity is 0.
It's even possible with the right combination of settings to make the vehicle slide up the slope. This is without any engine force or steering applied!

Steps to reproduce
Run the demo project
Minimal reproduction project (MRP)
VehicleBody Slope.zip

Hello, I'm a computer engineering college student and would like to take up the fixing of this bug. Would that be alright and is there any more convenient way I can keep in contact if questions come up?

Hello, I'm a computer engineering college student and would like to take up the fixing of this bug. Would that be alright and is there any more convenient way I can keep in contact if questions come up?

You are very welcome to fix this bug and post your progress or potential issues in this thread.
But a fair warning: the physics side of Godot isn't well maintained and you will probably be more or less on your own with this. I think I read somewhere that the Vehiclebody was originally ported from the Bullet Physics source code..

Hello, I'm a computer engineering college student and would like to take up the fixing of this bug. Would that be alright and is there any more convenient way I can keep in contact if questions come up?

You are very welcome to fix this bug and post your progress or potential issues in this thread. But a fair warning: the physics side of Godot isn't well maintained and you will probably be more or less on your own with this. I think I read somewhere that the Vehiclebody was originally ported from the Bullet Physics source code..

Sorry for the delay on my response. First of all thank you very much for the opportunity of working on this bug. Second of all I had a few questions regarding the expected result and standards of the godot engine:

Is the vehicle supposed to also not slide down when moving forward on a slope? Or is it only when parked?
Is there supposed to be a difference between a vehicle being still and a being parked or is it considered the same on the engine?
Is there any moment where it should be sliding (low friction floor for example) and should the traction of the vehicle be calculated with the vehicle as a whole or taking into account each tire it has?

Thank you for your time

So I don't think I'm really qualified to answer that all. I have never contributed to the engine and don't know much about how it works internally or is supposed to worked. I just filed that bug report..

Is the vehicle supposed to also not slide down when moving forward on a slope? Or is it only when parked?

I think, from an end-user perspective, I don't want it to slide unless the friction of the surface is low. Like on ice, for example.

Is there supposed to be a difference between a vehicle being still and a being parked or is it considered the same on the engine?

I have no idea, but I think for all intents and purposes this can handled as the same case.

Is there any moment where it should be sliding (low friction floor for example) and should the traction of the vehicle be calculated with the vehicle as a whole or taking into account each tire it has?

See above and I think i already does it per wheel, but I might be wrong.

Would love to see this fixed some day, seems to be gettings worse over time (tested on 4.4 dev)

Not just sideways. If you're on a slope, vehicle will slide down, regardless of your angle. Engine is not calculating the gravity by checking the normal of the floor, therefore vehicle has to be on a perfectly flat ground to stand still.

Just so this doesn't get picked up again, I have the unfortunate news that I was not able to fix this bug after a lot of different attempts. As I have ran out of ideas, I will have to drop this bug fix, sorry for the time I took in attempting to make it work and without response. If anyone wants to pick this up, I will gladly share notes of what I found that could perhaps help.


dosent send to discord

i set it all up but when i test it it dosent send to discord

bro how tf am i supposed to help when i dont get an error i can't magically figure out what's the problem

there is no error lmao

so when you double clikc the final exe file nothing happens??

Barring no further 'issues' (pun intended), this will be closed in 52 hours.

everything should be fixed now, make sure to try it and tell if it works fine for you now!


[Sponge] Error with ComputerCraft Turtles

This issue happens whenever isBlockProtected is fired, which calls ChangeBlockEvent.Pre, which GriefPrevention listens on and requests the permission related to it. This seems to fail for some reason.
It also fails on PermissionsEx.
[00:00:14] [Server thread/ERROR] [Sponge]: Could not pass ChangeBlockEvent$Pre$Impl to Plugin{id=griefprevention, name=GriefPrevention, version=2.2.0, description=This plugin is designed to prevent all forms of grief., source=/opt/mcf/mods/griefprevention-1.10.2-<IP_ADDRESS>.jar}
java.lang.NullPointerException
        at me.lucko.luckperms.sponge.service.LuckPermsService.lambda$convertContexts$0(LuckPermsService.java:173) ~[LuckPermsService.class:?]
        at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) ~[?:1.8.0_91]
        at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1540) ~[?:1.8.0_91]
        at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:1.8.0_91]
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:1.8.0_91]
        at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) ~[?:1.8.0_91]
        at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_91]
        at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) ~[?:1.8.0_91]
        at me.lucko.luckperms.sponge.service.LuckPermsService.convertContexts(LuckPermsService.java:173) ~[LuckPermsService.class:?]
        at me.lucko.luckperms.sponge.service.LuckPermsSubject.getPermissionValue(LuckPermsSubject.java:47) ~[LuckPermsSubject.class:?]
        at net.minecraft.entity.player.EntityPlayerMP.getPermissionValue(EntityPlayerMP.java:148) ~[lu.class:?]
        at me.ryanhamshire.griefprevention.GPPermissionHandler.getUserPermission(GPPermissionHandler.java:115) ~[GPPermissionHandler.class:?]
        at me.ryanhamshire.griefprevention.GPPermissionHandler.getClaimPermission(GPPermissionHandler.java:83) ~[GPPermissionHandler.class:?]
        at me.ryanhamshire.griefprevention.claim.Claim.allowBuild(Claim.java:504) ~[Claim.class:?]
        at me.ryanhamshire.griefprevention.GriefPrevention.allowBuild(GriefPrevention.java:1186) ~[GriefPrevention.class:?]
        at me.ryanhamshire.griefprevention.event.BlockEventHandler.onBlockPre(BlockEventHandler.java:131) ~[BlockEventHandler.class:?]
        at org.spongepowered.common.event.listener.PreListener_BlockEventHandler_onBlockPre66.handle(Unknown Source) ~[?:?]
        at org.spongepowered.common.event.RegisteredListener.handle(RegisteredListener.java:95) ~[RegisteredListener.class:1.10.2-2123-5.1.0-BETA-1923]
        at org.spongepowered.mod.event.SpongeModEventManager.post(SpongeModEventManager.java:357) [SpongeModEventManager.class:1.10.2-2123-5.1.0-BETA-1923]
        at org.spongepowered.mod.event.SpongeModEventManager.post(SpongeModEventManager.java:398) [SpongeModEventManager.class:1.10.2-2123-5.1.0-BETA-1923]
        at org.spongepowered.mod.event.SpongeModEventManager.post(SpongeModEventManager.java:370) [SpongeModEventManager.class:1.10.2-2123-5.1.0-BETA-1923]
        at org.spongepowered.common.SpongeImpl.postEvent(SpongeImpl.java:141) [SpongeImpl.class:1.10.2-2123-5.1.0-BETA-1923]
        at net.minecraft.server.dedicated.DedicatedServer.func_175579_a(DedicatedServer.java:110) [ld.class:?]
        at dan200.computercraft.ComputerCraft.isBlockEnterable(ComputerCraft.java:454) [ComputerCraft.class:?]
        at dan200.computercraft.shared.turtle.core.TurtleMoveCommand.canEnter(TurtleMoveCommand.java:163) [TurtleMoveCommand.class:?]
        at dan200.computercraft.shared.turtle.core.TurtleMoveCommand.execute(TurtleMoveCommand.java:45) [TurtleMoveCommand.class:?]
        at dan200.computercraft.shared.turtle.core.TurtleBrain.updateCommands(TurtleBrain.java:998) [TurtleBrain.class:?]
        at dan200.computercraft.shared.turtle.core.TurtleBrain.update(TurtleBrain.java:185) [TurtleBrain.class:?]
        at dan200.computercraft.shared.turtle.blocks.TileTurtle.func_73660_a(TileTurtle.java:259) [TileTurtle.class:?]
        at org.spongepowered.common.event.tracking.TrackingUtil.tickTileEntity(TrackingUtil.java:211) [TrackingUtil.class:1.10.2-2123-5.1.0-BETA-1923]
        at net.minecraft.world.WorldServer.redirect$onUpdateTileEntities$zjk000(WorldServer.java:1298) [ls.class:?]
        at net.minecraft.world.World.func_72939_s(World.java:1282) [aid.class:?]
        at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:713) [ls.class:?]
        at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:709) [MinecraftServer.class:?]
        at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:387) [ld.class:?]
        at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:613) [MinecraftServer.class:?]
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:471) [MinecraftServer.class:?]
        at java.lang.Thread.run(Thread.java:745) [?:1.8.0_91]

Not sure if this is relevant information but I found that everybodys name is null after a migration from PermissionsEx:
{
    "uuid": "c1ca957e-fb26-4ea0-b339-20802fcf2d33",
    "name": "null",
    "primaryGroup": "default",
    "perms": {
        "group.default": true,
        "meta.name.086": true,
        "(gp_claim=8ae7bdd2-a235-4622-a574-07fb8ba72ec3)griefprevention.claim.flag.enter-claim": false
    }
}

Apparently this is a problem on GriefPreventions end. However, the name thing is still an issue.

I fixed the context issue. I do have confirmations about the null name after PEX migrations.

The null username issue will be fixed when the Sponge permission API receives it's update for version 6.0.0.
The issue is, currently, other plugins are requesting the user before they've been handled by LuckPerms as a normal player on the standard login events. I can't really fix that easily until the API is changed.
(not entirely true, it's just a real pain to fix.)
I am hopeful that the Sponge updates will be pushed soon, and I can then update LP shortly afterwards and cleanup these remaining issues.

The username though is stored in the config file, just not in the correct location.

Correct location, not sure what you mean by that?

meta.name is correct, but the name at the top is not.

Meta.name would've come from the PEX migration, I don't set that.

Closing this since the NPE with GP was fixed. I've opened a new issue for the null name & JSON storage issue.


OpenVINO bloat

Comment:
Is it really necessary to bundle in OpenVINO? It significantly increases the size of this package, for a feature that 99.99% of the users will not need.

hmm, this is a fair question.
@ilya-lavrenov can you help us understand all the different intel solutions:

OpenVINO
VAAPI
Intel Quick Sync

@ilya-lavrenov I know ffmpeg supports many "hot" plugins. Can we have openvino as a "soft" dependency similar to how the cuda dependency will "gracefully fail" if cuda isn't installed on the end user system?

Regarding:

for a feature that 99.99% of the users will not need.

Much of FFMPEG's strength comes from its great flexibility. Each users likely only uses 1-2 features, but FFMPEG makes them all interoperable.

It seems that compiling with openvino makes it a hard dependency:
conda uninstall --force libopenvino --offline --yes
ffmpeg -hide_banner -f lavfi -i nullsrc=s=256x256:d=8 -vcodec libopenh264 -f null -
ffmpeg: error while loading shared libraries: libopenvino_c.so.2440: cannot open shared object file: No such file or directory


hare: cache tortoise active set

related: https://github.com/spacemeshos/go-spacemesh/issues/4164
without cache hare doesn't work with large number of activations, as it takes too long if eligibility verification triggers load of 1000s of activations for every single message

bors merge

bors merge

bors merge


[Question] add_generation_prompt=True on prompt

Hi,
I noticed that from v0.11.0, maybe_apply_chat_template added generation prompt on the prompt of the example, which was different from the previous version.
https://github.com/huggingface/trl/blob/0238d96c6f43abd808804ddb0065883964073060/trl/data_utils.py#L86-L88
Was it a little bug? Will the generation prompt influence the final result?
A prompt reply is appreciated.

Can you point the "previous version" you are refering to?

I think it has been like this from the initial implementation (see #2020)

I think it has been like this from the initial implementation (see #2020)

Sorry, I didn't say that right. I mean before v0.11.0, there was no  maybe_apply_chat_template back then.  For example, the dpo dataset was preprocessed like:
https://github.com/huggingface/trl/blob/55cc4b1076144b74a6ce5d07557b7f664b1de8d9/examples/scripts/dpo.py#L156-L160
Since the code has been refactored , I'm not sure if there was generation prompt or not. If so, could you please point out where it was implemented?

Yes the example code was wrong, you need to add a generation prompt at the end of the prompt.

Yes the example code was wrong, you need to add a generation prompt at the end of the prompt.

I see. Thanks a lot!


Updated CMakeLists to work with GEOS-ESMA/ESMA_cmake#57

This PR accompanies GEOS-ESM/ESMA_cmake#57

This diff here is actually a bit misleading. There are two things going on

A line was added linking the base target, Baselibs, into GMAO_mpeu
The lines linking/including MPI were removed because they are redundant (link libraries and include directories are propoagated transitively through the base target Baselibs).

@LiamBindle I don't think that answers my concern.   MPEU's only dependence is on MPI.   It does  not, nor should it depend on baselibs.   Yes, baselibs does provide MPI but the general philosophy I've been following is to keep explicit (non transitive) dependencies when a package directly uses the dependency.   Consider the case where component A depends directly on B and C, but B also depends directly on C.   We could just say that A depends on B, but if the implementation of B changes such that it no longer depends on C, then A is now broken for no good reason.
And I'm still confused as to why you were even looking inside MPEU.   The MPI dependency should not have triggered any errors in your configuration - at least I don't immediately see how.

@tclune
I'm linking Baselibs into MPEU because MPEU is a leaf in MAPL's dependency-tree and Baselibs is an interface target that provides (a) the global GEOS compiler options set in esma.cmake, (2) the global pre-processor definitions defined in FindBaselibs.cmake, and (3) Baselibs. Essentially, I'm using MPEU (and GMAO_pFIO and MAPL_cfio) as a means of distributing global build properties to the rest of the MAPL build tree.
Sorry, it wasn't obvious what all the Baselibs interface target has actually been providing—I could fix that by separating the build properties out into their own interface target (and maybe getting rid of the Baselibs target all together).
The basic problem I was trying to solve was how do I make sure all GEOS-ESM libraries (now and in the future)

are compiled with the expected compiler options (set globally here)
are compiled with the appropriate pre-processor definitions (some of which are set globally here)
paths to external dependencies are resolved correctly (include directories, link libraries, compiler options, etc.)

and that GEOS-ESM's build properties don't conflict/have unintended consequences for GEOS-Chem's build—for example, something like -DHAS_NETCDF3 (from GEOS-ESM) turning on an unexpected block of code in GEOS-Chem (more subtle unintended consequences are possible with compiler options).
I'll skip over 3 because it's relatively easy to ensure with find_package() calls and the standard variables/targets defined by those calls. And points 1 and 2 are essentially the same problem, and I've described the two general approaches I can think of below.
The first, and current, approach is to set compiler options and definitions globally for the entire directory-tree that calls include(esma). This provides comprehensive control but means sub-projects within that tree are affected too. For example, with GCHPctm's current directory structure, all of GEOS-Chem would be compiled with definitions like -DHAS_NETCDF3 and GEOS's compiler options.
Another—my proposed—approach is to control GEOS-ESM libraries' compiler options and definitions through interface target(s) that they "link". This approach also provides comprehensive control of GEOS-ESM targets, but it doesn't affect non-GEOS-ESM targets. I opted for a single interface target to control these build properties, but multiple interface targets could be used to provide groups of build properties (e.g. for vectorized code). For GEOS-ESM libraries to get their compiler options and definitions they have to either (a) all explicitly "link" the interface target(s) with the INTERFACE keyword, or (b) the interface target(s) have to be "linked" with the PUBLIC keyword at strategic spots so that their properties are transitively propagated upwards. I opted for (b) because to minimize the diff (the strategic spots being GMAO_mpeu, GMAO_pFIO, and MAPL_cfio), and I lumped this single interface target into the Baselibs target.
Lumping the interface target with GEOS-ESM-wide build properties into Baselibs probably wasn't a good idea though, because it isn't obvious Baselibs also provides compiler options and preprocessor definitions.
So in summary, Baselibs is "linked" into GMAO_mpeu because that's how GMAO_mpeu and all its dependents get their compiler options and definitions. Baselibs also resolves the MPI dependency but unnecessarily provides all the rest of Baselibs (but they are propagated upwards resolving dependents' other dependencies). This is also why GMAO_pFIO and MAPL_cfio "link" Baselibs with the PUBLIC keyword.
Below is a graphviz image of GCHPctm's dependency-tree. The edges between libraries linked with generator expressions don't show up properly, but you can still see the general structure.

What are your thoughts on controlling build properties with interface target(s) rather than the global function calls? It sounds like linking the build-properties-interface-target(s) with the INTERFACE keyword rather than the PUBLIC keyword would be more inline with the current philosophy—is that right? In that case, every target would explicitly link its dependencies and the build-property-interface-target with the INTERFACE keyword.

OK - I need to look into this.  MAPL should not be depending on mpeu.  Nor should mpeu depend on MAPL.   They have some overlapping roles, but mpeu is definitely the deprecated older layer.   Some of the assimilation folk have some pet features in there that have not (yet) been replicated in MAPL, or we'd have scrapped it already.
I completely agree that we should not be using directory level compiler options wherever possible.  Partly this is because I was unaware of target-specific approaches when I started CMake (possibly they did not exist yet then?), but also because it was not always easy to see all of the intended effects as due to the complex use in the original GNU make scripts.
But ... even then,   a directory wide compiler option in our package should never pollute your components that use our components.   So the whole discussion seems to be a bit beside the point.
I don't fully understand INTERFACE targets.    For compiler options,  I've generally found that they should almost always be PRIVATE to the target for which they apply.

Happy to continue the discussion, but this particular change is unnecessary, and seems implies incorrect dependencies among components.   GMAO_mpeu has no dependency on baselibs, nor is there any dependency between MAPL and mpeu.

@tclune Yep, that's totally fair. Let's continue discussing the ESMA_cmake changes, but I think it makes sense to close this one.


Jupyter Notebook - Option to Disable Wordwrap in Cell Results

Hi,
Feature / Issue
It would be great to be able to disable word wrapping in Jupyter Notebook Cell Results
Currently if you have a dataframe with a large number of columns or a dataframe with long fields or field names the results end up wrapping and the results are unreadable.
My current work around is to copy and paste the results into Notepad++ to view them there which is a pretty poor experience.
Searching and posting questions via Stackoverflow hasn't resulted in a way around this :(
System details
VS Code 1.46
Windows 10 20.04
Sample Result

Sample Code
Sample code to generate a wide Pyspark dataframe that will wrap ....
spark.sql("select 'field1field1field1' as field1, 'field2field2field2' as field2, 'field3field3field3' as field3, 'field4field4field4' as field4, 'field5field5field5' as field5, 'field6field6field6' as field6, 'field7field7field7' as field7, 'field8field8field8' as field8, 'field9field9field9' as field9, 'field10field10field10' as field1, 'field11field11field11' as field11, 'field12field12field12' as field12, 'field13field13field13' as field13, 'field14field14field14' as field14, 'field15field15field15' as field15, 'field16field16field16' as field16, 'field17field17field17' as field17, 'field18field18field18' as field18, 'field19field19field19' as field19, 'field1field1field1' as field1, 'field2field2field2' as field2, 'field3field3field3' as field3, 'field4field4field4' as field4, 'field5field5field5' as field5, 'field6field6field6' as field6, 'field7field7field7' as field7, 'field8field8field8' as field8, 'field9field9field9' as field9, 'field10field10field10' as field1, 'field11field11field11' as field11, 'field12field12field12' as field12, 'field13field13field13' as field13, 'field14field14field14' as field14, 'field15field15field15' as field15, 'field16field16field16' as field16, 'field17field17field17' as field17, 'field18field18field18' as field18, 'field19field19field19' as field19").show(10, False)

Please file this issue against the Python extension.