text:
Publish new package version on NPM

The currently published 1.4.0 is over a year old.
Would it be possible to publish a new version? This would make it easy to use newer versions through unpkg.

Very good point, thank you for reminding! We were mainly focused on releasing label-studio package and enterprise version of it, but nothing stops us from releasing LSF as well!
We will publish it soon and notify you here.

How soon is "soon"?

A release would be awesome. It looks like the currently published version of LSF is incompatible with e.g. the latest label-studio-converter, which makes it hard to setup a complete workflow without having to opt into full LS.

Also, if you guys updated the core LS repo to consume this repo as an NPM package instead of a git submodule, this package would always be up to date for you and the public, with no extra work needed on your part, especially since you're already using conventional commits in this repo!

Hey guys, I finally convinced our frontend team to make regular releases for LSF. So, waiting for their solution and continue pinging them.

Yeah, waiting for that

authors: costika1234 epeters3 hansihe hlomzik juhonkang makseq

repo: heartexlabs/label-studio-frontend


text:
Endless exporting

Describe the bug
Export project to COCO format. Endless (i waited 24 hours) exporting without downloading.
To Reproduce
Steps to reproduce the behavior:

Go to project
Click on Export, chose COCO format
Click on Export button.
I don't see any error

Expected behavior
I wanted to download the COCO format from the project.
Screenshots

Environment (please complete the following information):

OS: Win10
Label Studio Version [1.6.0]

Additional context
As long as I didn't use the labels to the images, I could export the COCO format....
Thank you guys for reply ! :)

Please try to use this command:
https://labelstud.io/guide/export.html#Export-using-console-command
"Export using console command"

source: gharchive/issue

repo: heartexlabs/label-studio

license_type: permissive

license_source: github-api


text:
cmake: Regular rebasing of the cmake-staging branch

This is the cmake-staging branch rebased on the recent bitcoin/master branch, which includes the main build system changes, with the squashed "!fixup" commits.
Steps to reproduce:

Run the command as follows:

git checkout 3c740846bf0ffb8eecb56585cb35d936d73f3af8
git rebase -i --autosquash d7333ece15b8a9c941af072cebc210b099900d0e

There are a few conflicts that have to be resolved.

Squash "[FIXUP]" commits that were not handled automatically (there must be a zero-diff change).

Reorder commits to make their history suitable for https://github.com/bitcoin/bitcoin/pull/30454 (there must be a zero-diff change).

ACK a247573c8f7652b30843e3114d597645694c1dec
Didn't manage to get a clean rebase but I can see the code I have extra was removed here: https://github.com/hebasto/bitcoin/pull/307/files so it must be my poor rebasing skills again.
Guix is building

@m3dwards
Thank you for your review!

This branch has been force pushed into the https://github.com/hebasto/bitcoin/tree/cmake-staging.
Closing.

My Guix build:
x86_64
5c2bc3135419814a563d30ccc130a75b8dbacc3308394c59de0b4d3a85bfacd3  guix-build-a247573c8f76/output/aarch64-linux-gnu/SHA256SUMS.part
39340772554a0d4b1028627916fe86fcf428472952141bdb4f4fe96e88ec4ff2  guix-build-a247573c8f76/output/aarch64-linux-gnu/bitcoin-a247573c8f76-aarch64-linux-gnu-debug.tar.gz
51719dd9095477d74bb1c50333615e46ce15e491a841ee73753aabbb6c73577b  guix-build-a247573c8f76/output/aarch64-linux-gnu/bitcoin-a247573c8f76-aarch64-linux-gnu.tar.gz
336feb70ec077679fa08c3ab9338e8b31c317fd3d1d2575243b6379244937ac2  guix-build-a247573c8f76/output/arm-linux-gnueabihf/SHA256SUMS.part
3c91da4f74ac8c3d55971fbcb676732eee766f600fb4220066224327f275722f  guix-build-a247573c8f76/output/arm-linux-gnueabihf/bitcoin-a247573c8f76-arm-linux-gnueabihf-debug.tar.gz
9c258dfa9479ff50d2c995e3e0bc1f4158abd62707d98db23f52400ebe662484  guix-build-a247573c8f76/output/arm-linux-gnueabihf/bitcoin-a247573c8f76-arm-linux-gnueabihf.tar.gz
964b76b8ec018cc3f380adfd93b143115ad6128aade3195c64106b6360579b78  guix-build-a247573c8f76/output/arm64-apple-darwin/SHA256SUMS.part
d026fe409d12eaaa551eb41ee913c6a3968b71b30000e883296846f1d2639734  guix-build-a247573c8f76/output/arm64-apple-darwin/bitcoin-a247573c8f76-arm64-apple-darwin-unsigned.tar.gz
62c3264a9a45410ce03df57092d0e6b63c3407c561a9d9c3fcd8aab97907d44d  guix-build-a247573c8f76/output/arm64-apple-darwin/bitcoin-a247573c8f76-arm64-apple-darwin-unsigned.zip
0939ec31268be1a50fff4513b3dc02cf82ee64c0dca8b3ac633f0d6a0a8140fd  guix-build-a247573c8f76/output/arm64-apple-darwin/bitcoin-a247573c8f76-arm64-apple-darwin.tar.gz
611446c47246e326bf28902147c90fcb54aaf84a83cb638c3eda26ca37798e7a  guix-build-a247573c8f76/output/dist-archive/bitcoin-a247573c8f76.tar.gz
612165dc248315d385cb080e611516feddb0ec6652a29045fb5e003685cbd0cc  guix-build-a247573c8f76/output/powerpc64-linux-gnu/SHA256SUMS.part
5fdf7e2c72cac6059864ed8fe130c0eba0e41217d917d0030277e7b25685f7da  guix-build-a247573c8f76/output/powerpc64-linux-gnu/bitcoin-a247573c8f76-powerpc64-linux-gnu-debug.tar.gz
42012cb080d4a57d26688b85186864e74d18ddb8199659a3cd91ed8f5881a744  guix-build-a247573c8f76/output/powerpc64-linux-gnu/bitcoin-a247573c8f76-powerpc64-linux-gnu.tar.gz
e2e325ac379f8e96bc39a690ee92cd0b3e837d2fca32704beb42d03910be01ed  guix-build-a247573c8f76/output/riscv64-linux-gnu/SHA256SUMS.part
20f62341e951e0803b7c76f91bff25a95740cd91e5de189b95a8b40e7c6e9546  guix-build-a247573c8f76/output/riscv64-linux-gnu/bitcoin-a247573c8f76-riscv64-linux-gnu-debug.tar.gz
9c12a7a45b98c15ffaef9fa6d20e9a3517ec4d99a3c7bed0648a77010321b6c1  guix-build-a247573c8f76/output/riscv64-linux-gnu/bitcoin-a247573c8f76-riscv64-linux-gnu.tar.gz
7fbaa2ba40fa81edf9a0b8f57fb27a041b8d726be89dda259ffb2947fbd0b658  guix-build-a247573c8f76/output/x86_64-apple-darwin/SHA256SUMS.part
11241a2359b3cb7d0bb5a334c76a38d167fb8814d836db209df05ff335b6f964  guix-build-a247573c8f76/output/x86_64-apple-darwin/bitcoin-a247573c8f76-x86_64-apple-darwin-unsigned.tar.gz
54c08c37af8b03397bee92558d838081ad5e4e57e0bdb9e8e59cb0c483899947  guix-build-a247573c8f76/output/x86_64-apple-darwin/bitcoin-a247573c8f76-x86_64-apple-darwin-unsigned.zip
bd93219ef937152f511106a9c780ac550a6e235cc2695d58d78078832da1ba77  guix-build-a247573c8f76/output/x86_64-apple-darwin/bitcoin-a247573c8f76-x86_64-apple-darwin.tar.gz
76c09f001e038891f4532f915ccf232a018e41e15765cbcc07ec2f95db6835ab  guix-build-a247573c8f76/output/x86_64-linux-gnu/SHA256SUMS.part
c91f1e6590d69371ecc1c77d3c91b2b57d048c9c303550a34a4be82b7b231378  guix-build-a247573c8f76/output/x86_64-linux-gnu/bitcoin-a247573c8f76-x86_64-linux-gnu-debug.tar.gz
da75dbc23ea475fb24b9badaf37729591193f2f6faddc37e52250c0ce28731b2  guix-build-a247573c8f76/output/x86_64-linux-gnu/bitcoin-a247573c8f76-x86_64-linux-gnu.tar.gz
4146dcf24c40406d657619d318df9bf04c8d534352513f7b2edb29515cac586a  guix-build-a247573c8f76/output/x86_64-w64-mingw32/SHA256SUMS.part
a2da7cc31088937a7c685443550401ed49bc264a3c62c7ce935d135e8964f1f6  guix-build-a247573c8f76/output/x86_64-w64-mingw32/bitcoin-a247573c8f76-win64-debug.zip
65e44df75e0171b029a6148c2c978d42dd265f42d8e4c184d62b9a0e114dbc51  guix-build-a247573c8f76/output/x86_64-w64-mingw32/bitcoin-a247573c8f76-win64-setup-unsigned.exe
efa39e967495a2c9b9a4b0ec36ff2ebb988cf862ba4c6ad51d3a85a5bb2ba63b  guix-build-a247573c8f76/output/x86_64-w64-mingw32/bitcoin-a247573c8f76-win64-unsigned.tar.gz
f5357a598f406eff6bc4d88356978842c9df780e09daa58bd703c5ebe11c8076  guix-build-a247573c8f76/output/x86_64-w64-mingw32/bitcoin-a247573c8f76-win64.zip

Post close guix build (x86)
5c2bc3135419814a563d30ccc130a75b8dbacc3308394c59de0b4d3a85bfacd3  guix-build-a247573c8f76/output/aarch64-linux-gnu/SHA256SUMS.part
39340772554a0d4b1028627916fe86fcf428472952141bdb4f4fe96e88ec4ff2  guix-build-a247573c8f76/output/aarch64-linux-gnu/bitcoin-a247573c8f76-aarch64-linux-gnu-debug.tar.gz
51719dd9095477d74bb1c50333615e46ce15e491a841ee73753aabbb6c73577b  guix-build-a247573c8f76/output/aarch64-linux-gnu/bitcoin-a247573c8f76-aarch64-linux-gnu.tar.gz
336feb70ec077679fa08c3ab9338e8b31c317fd3d1d2575243b6379244937ac2  guix-build-a247573c8f76/output/arm-linux-gnueabihf/SHA256SUMS.part
3c91da4f74ac8c3d55971fbcb676732eee766f600fb4220066224327f275722f  guix-build-a247573c8f76/output/arm-linux-gnueabihf/bitcoin-a247573c8f76-arm-linux-gnueabihf-debug.tar.gz
9c258dfa9479ff50d2c995e3e0bc1f4158abd62707d98db23f52400ebe662484  guix-build-a247573c8f76/output/arm-linux-gnueabihf/bitcoin-a247573c8f76-arm-linux-gnueabihf.tar.gz
964b76b8ec018cc3f380adfd93b143115ad6128aade3195c64106b6360579b78  guix-build-a247573c8f76/output/arm64-apple-darwin/SHA256SUMS.part
d026fe409d12eaaa551eb41ee913c6a3968b71b30000e883296846f1d2639734  guix-build-a247573c8f76/output/arm64-apple-darwin/bitcoin-a247573c8f76-arm64-apple-darwin-unsigned.tar.gz
62c3264a9a45410ce03df57092d0e6b63c3407c561a9d9c3fcd8aab97907d44d  guix-build-a247573c8f76/output/arm64-apple-darwin/bitcoin-a247573c8f76-arm64-apple-darwin-unsigned.zip
0939ec31268be1a50fff4513b3dc02cf82ee64c0dca8b3ac633f0d6a0a8140fd  guix-build-a247573c8f76/output/arm64-apple-darwin/bitcoin-a247573c8f76-arm64-apple-darwin.tar.gz
611446c47246e326bf28902147c90fcb54aaf84a83cb638c3eda26ca37798e7a  guix-build-a247573c8f76/output/dist-archive/bitcoin-a247573c8f76.tar.gz
612165dc248315d385cb080e611516feddb0ec6652a29045fb5e003685cbd0cc  guix-build-a247573c8f76/output/powerpc64-linux-gnu/SHA256SUMS.part
5fdf7e2c72cac6059864ed8fe130c0eba0e41217d917d0030277e7b25685f7da  guix-build-a247573c8f76/output/powerpc64-linux-gnu/bitcoin-a247573c8f76-powerpc64-linux-gnu-debug.tar.gz
42012cb080d4a57d26688b85186864e74d18ddb8199659a3cd91ed8f5881a744  guix-build-a247573c8f76/output/powerpc64-linux-gnu/bitcoin-a247573c8f76-powerpc64-linux-gnu.tar.gz
e2e325ac379f8e96bc39a690ee92cd0b3e837d2fca32704beb42d03910be01ed  guix-build-a247573c8f76/output/riscv64-linux-gnu/SHA256SUMS.part
20f62341e951e0803b7c76f91bff25a95740cd91e5de189b95a8b40e7c6e9546  guix-build-a247573c8f76/output/riscv64-linux-gnu/bitcoin-a247573c8f76-riscv64-linux-gnu-debug.tar.gz
9c12a7a45b98c15ffaef9fa6d20e9a3517ec4d99a3c7bed0648a77010321b6c1  guix-build-a247573c8f76/output/riscv64-linux-gnu/bitcoin-a247573c8f76-riscv64-linux-gnu.tar.gz
7fbaa2ba40fa81edf9a0b8f57fb27a041b8d726be89dda259ffb2947fbd0b658  guix-build-a247573c8f76/output/x86_64-apple-darwin/SHA256SUMS.part
11241a2359b3cb7d0bb5a334c76a38d167fb8814d836db209df05ff335b6f964  guix-build-a247573c8f76/output/x86_64-apple-darwin/bitcoin-a247573c8f76-x86_64-apple-darwin-unsigned.tar.gz
54c08c37af8b03397bee92558d838081ad5e4e57e0bdb9e8e59cb0c483899947  guix-build-a247573c8f76/output/x86_64-apple-darwin/bitcoin-a247573c8f76-x86_64-apple-darwin-unsigned.zip
bd93219ef937152f511106a9c780ac550a6e235cc2695d58d78078832da1ba77  guix-build-a247573c8f76/output/x86_64-apple-darwin/bitcoin-a247573c8f76-x86_64-apple-darwin.tar.gz
76c09f001e038891f4532f915ccf232a018e41e15765cbcc07ec2f95db6835ab  guix-build-a247573c8f76/output/x86_64-linux-gnu/SHA256SUMS.part
c91f1e6590d69371ecc1c77d3c91b2b57d048c9c303550a34a4be82b7b231378  guix-build-a247573c8f76/output/x86_64-linux-gnu/bitcoin-a247573c8f76-x86_64-linux-gnu-debug.tar.gz
da75dbc23ea475fb24b9badaf37729591193f2f6faddc37e52250c0ce28731b2  guix-build-a247573c8f76/output/x86_64-linux-gnu/bitcoin-a247573c8f76-x86_64-linux-gnu.tar.gz
4146dcf24c40406d657619d318df9bf04c8d534352513f7b2edb29515cac586a  guix-build-a247573c8f76/output/x86_64-w64-mingw32/SHA256SUMS.part
a2da7cc31088937a7c685443550401ed49bc264a3c62c7ce935d135e8964f1f6  guix-build-a247573c8f76/output/x86_64-w64-mingw32/bitcoin-a247573c8f76-win64-debug.zip
65e44df75e0171b029a6148c2c978d42dd265f42d8e4c184d62b9a0e114dbc51  guix-build-a247573c8f76/output/x86_64-w64-mingw32/bitcoin-a247573c8f76-win64-setup-unsigned.exe
efa39e967495a2c9b9a4b0ec36ff2ebb988cf862ba4c6ad51d3a85a5bb2ba63b  guix-build-a247573c8f76/output/x86_64-w64-mingw32/bitcoin-a247573c8f76-win64-unsigned.tar.gz
f5357a598f406eff6bc4d88356978842c9df780e09daa58bd703c5ebe11c8076  guix-build-a247573c8f76/output/x86_64-w64-mingw32/bitcoin-a247573c8f76-win64.zip

source: gharchive/pull-request

repo: hebasto/bitcoin

license: MIT


text:
The category of a paper should be change.

Hi heejkoo,
The paper "DisDiff: Unsupervised Disentanglement of Diffusion Probabilistic Models" should belong to Vision/Generation but not 3D vision instead, because the paper is focus on learning disentangled representation of 2D images.
Thanks,
Thomas

It has changed. Thank you !

authors: ThomasMrY heejkoo

repo: heejkoo/Awesome-Diffusion-Models


text:
Prevent tiles from appearing inside buildings

create an empty prototype for interiors only and adapt the faces with an exterior and interior side

Note : this is currently caused by the current model set. They don't distinguish between "inside" and "outside" (i.e. the wall has two face what can have "outside blank". This issue can be resolved by making a more complexe model set.


text:
The 'search' property should accept 'null' or 'undefined' value

When there is nothing to search, the 'search' property of the component should accept null or undefined value to signify that nothing should be searched and the component should return the child 'as is'.
Currently, React throws
Warning: Failed prop type: The prop `search` is marked as required in `Highlighter`, but its value is `null`.
warning.js:33
    in Highlighter

when null is passed to the 'search' prop.

I think you can pass false if there is nothing to search.
<Highlight search={highlightRegexp || false}>{text}</Highlight>

From looking at the code, you can indeed pass false or even '' and it would act the same as not having received the search prop
    search: PropTypes.oneOfType([
      PropTypes.string,
      PropTypes.number,
      PropTypes.bool,
      RegExpPropType
    ]).isRequired,

  hasSearch: function() {
    return (typeof this.props.search !== 'undefined') && this.props.search;
  },

However, the undefined case is explicitly being supported in the hasSearch function, but then made fail by propTypes.
Moreover (typeof this.props.search !== 'undefined') && this.props.search is the same as this.props.search for the purposes of this code.
Removing the isRequired from the propTypes would spare me from having to transform
{...props} into {...props} search={props.search || false}
Actually the very existence of the function hasSearch opposes the usage of isRequired

authors: Gsiete kachkaev orobert91

repo: helior/react-highlighter

license: mit

license_source: bigquery


text:
[Addition]: PantherX Cluster in US (14 HS)

Hotspot b58 Addresses
11Eu4fQeHWpmzK7FdxMCkSgDDGHTcoBZDmgKDg5v9y1DyhbuCN4
112PP8gkp7chV5eA1V6RkW6rYvFZTyBYFb6xs6PGD8ZjcYdZRJaT
11snoaGNMkZ56NnZZdBcJdpjX9VCuJgjaEhMtJYp8hXeoDBTPUh
11TECZEtW73UNUQJk6551xeBLn4tsccY8mTZXx3BSsRY3eos4mt
112WyJMwdrFZqRTEE9SPmj99muUYXonfXgQZTVsCTupdZpXSKZQJ
112RpfTshA2BhqEocwYKxbh7GEDKZ2mTYBUfJQ1y5zttEGts8941
112p9yjcRFWvqxcAQXemfPY3zmPEGUrrrwmdK4YHNgCocRDUj1mn
117YoBUY8643NeezYmmNVzEwKiTcbd8mnREeTKjrpSfTi7Y8zzi
112oaFCiPXPBQnbRuKSRH47jP9a5c3jj4iTQ6YBxdnENoPC5Qudy
11EeNDFY9aWH5ZV9fLj1SS9N7DFJ7kfuGBgck1jw3nsowHYo2G7
112RVwzk1q3K6hDh4nX88e155iZnNt9PEFkXBpf9wgHwNYsHctu9
1127ohmjCLeLyjNNpJ84QxDkFGs92CichBWrMWNbf7AeT6UeC7kz
112JT7AF3iNYGvJ5tX4qzdFayWU4NerPqyVeoUnJJrZE5Vmuus1L
112RwPzGMuhpK9rE6D9YsVuiNstUCzDwGwEzDCfM19ZCXgfbTKhP
Discord Handle
No response
Reason(s)
Self witnessing cluster near city

Abnormal RSS

query_result_2022-07-24T01_37_55.629246-04_00.csv

lol a fun human intervention project (including a bunch of upstanding idiots)
The floor layout of the same building cannot be more than multiple devices? You buy equipment that can be deployed,
I bought it and can't deploy it?
The project is deceiving itself, you are here to ask for justice?
interesting. 99% of the world cheats. How much is actually deployed, do you see it?
The project party itself does not understand the future of this project, you are just chicken nuggets, fools.
Helium can't develop, it's not that helium is bad, it's you who pretended to be serious and ruined it. Ha ha
A project without funding, this project is a piece of shit,
BTC EHT has no miners, it is just something mocked by capital, HELUIM has no capital miners, it is a garbage coin of $0.000000000005
Did you raise HELIUM by $100? Ha ha
If you continue to install justice, the project party cannot sell the mining machine, and HELIUM will be destroyed at that time. I see how your clown pretend justice
OMG, poor I bought 10 LELIUMM miners and deployed them in real life. Each machine mines 0.01 coins per day. LOL.

lol, the clown is doing justice

query_result_2022-07-24T01_37_55.629246-04_00.csv
a fool and a lunatic

repo: helium/denylist


text:
[Addition]: Suspicous gamer

Hotspot b58 Addresses
112WjQnbwn1Pk43hEYGXKaenjsXR65drsXSWJy19rwxXfFYpwJNZ
Discord Handle
No response
Reason(s)
According to the coordinate, the hotspot is located in a center of a natural park, there is completely no infrastructure in that park, besides, there is also no tall building nearby. It is not possible to put antenna in 27 meters high inside the park.
Also the hotspot is relayed with so high earning compared to all the hotspots nearby, the number of witnessed is bizarre. Moreover, a 2.9 dBi antenna reaches 150 kilometers away!
This COTX hotspot also looks very similar and same pattern as several hotspots which have been already on the denylist in the area, as an example: https://explorer.helium.com/hotspots/11qxA35LEyibTA16szsvhoft4oJF2Hug7pwrrakp1QafjgX7dDs

Just an fyi...people are making off-grid solar powered units with cellular connections that can be in rote locations. Can you prove it's not? I'd say no, but here you are reporting some BC cause your setup sucks.

I am not the only one who reported this hotspot, it is also on the list of this issue: https://github.com/helium/denylist/issues/502


text:
[stable/mongodb] Install fails

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Version of Helm and Kubernetes:
Helm v2.11.0
Kubernetes v1.13.1
Which chart:
stable/mongodb
What happened:
Run
helm install --name mongodb --namespace database -f values-mongo.yaml stable/mongodb

helm status mongodb
LAST DEPLOYED: Wed Feb 13 10:31:30 2019
NAMESPACE: database
STATUS: DEPLOYED

RESOURCES:
==> v1beta1/PodDisruptionBudget
NAME               AGE
mongodb-arbiter    4m
mongodb-primary    4m
mongodb-secondary  4m

==> v1/Secret
mongodb  4m

==> v1/Service
mongodb-headless  4m
mongodb           4m

==> v1/StatefulSet
mongodb-arbiter    4m
mongodb-primary    4m
mongodb-secondary  4m

However that's as far as it gets. The persistent volumes are created, and the service configs are added too, but the services and pods are never created.
Bit lost as to where I can find the cause of it failing, my values are below
## Global Docker image registry
## Please, note that this will override the image registry for all the images, including dependencies, configured to use the global value
##
# global:
#   imageRegistry:

image:
  ## Bitnami MongoDB registry
  ##
  registry: docker.io
  ## Bitnami MongoDB image name
  ##
  repository: bitnami/mongodb
  ## Bitnami MongoDB image tag
  ## ref: https://hub.docker.com/r/bitnami/mongodb/tags/
  ##
  tag: 4.0.6

  ## Specify a imagePullPolicy
  ## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images
  ##
  pullPolicy: Always
  ## Optionally specify an array of imagePullSecrets.
  ## Secrets must be manually created in the namespace.
  ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
  ##
  # pullSecrets:
  #   - myRegistrKeySecretName

  ## Set to true if you would like to see extra information on logs
  ## It turns NAMI debugging in minideb
  ## ref:  https://github.com/bitnami/minideb-extras/#turn-on-nami-debugging
  debug: false

## Enable authentication
## ref: https://docs.mongodb.com/manual/tutorial/enable-authentication/
#
usePassword: true
# existingSecret: name-of-existing-secret

## MongoDB admin password
## ref: https://github.com/bitnami/bitnami-docker-mongodb/blob/master/README.md#setting-the-root-password-on-first-run
##
mongodbRootPassword: mypassword

## MongoDB custom user and database
## ref: https://github.com/bitnami/bitnami-docker-mongodb/blob/master/README.md#creating-a-user-and-database-on-first-run
##
# mongodbUsername: username
# mongodbPassword: password
# mongodbDatabase: database

## Whether enable/disable IPv6 on MongoDB
## ref: https://github.com/bitnami/bitnami-docker-mongodb/blob/master/README.md#enabling/disabling-ipv6
##
mongodbEnableIPv6: true

## MongoDB System Log configuration
## ref: https://github.com/bitnami/bitnami-docker-mongodb#configuring-system-log-verbosity-level
##
mongodbSystemLogVerbosity: 0
mongodbDisableSystemLog: false

## MongoDB additional command line flags
##
## Can be used to specify command line flags, for example:
##
## mongodbExtraFlags:
##  - "--wiredTigerCacheSizeGB=2"
mongodbExtraFlags: []

## Pod Security Context
## ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
##
securityContext:
  enabled: true
  fsGroup: 1001
  runAsUser: 1001

## Kubernetes Cluster Domain
clusterDomain: cluster.local

## Kubernetes service type
service:
  annotations: {}
  type: ClusterIP
  # clusterIP: None
  port: 27017

  ## Specify the nodePort value for the LoadBalancer and NodePort service types.
  ## ref: https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport
  ##
  # nodePort:

## Setting up replication
## ref: https://github.com/bitnami/bitnami-docker-mongodb#setting-up-a-replication
#
replicaSet:
  ## Whether to create a MongoDB replica set for high availability or not
  enabled: true
  useHostnames: true

  ## Name of the replica set
  ##
  name: dotrep

  ## Key used for replica set authentication
  ##
  key: mykey

  ## Number of replicas per each node type
  ##
  replicas:
    secondary: 1
    arbiter: 1
  ## Pod Disruption Budget
  ## ref: https://kubernetes.io/docs/concepts/workloads/pods/disruptions/
  pdb:
    minAvailable:
      primary: 1
      secondary: 1
      arbiter: 1

# Annotations to be added to MongoDB pods
podAnnotations: {}

# Additional pod labels to apply
podLabels: {}

## Configure resource requests and limits
## ref: http://kubernetes.io/docs/user-guide/compute-resources/
##
resources:
  limits:
    cpu: 500m
    memory: 1.5G
  requests:
    cpu: 256Mi
    memory: 1G

## Pod priority
## https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/
# priorityClassName: ""

## Node selector
## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector
nodeSelector:
  servertype: mongo

## Affinity
## ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
affinity: {}

## Tolerations
## ref: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
tolerations: []

## Enable persistence using Persistent Volume Claims
## ref: http://kubernetes.io/docs/user-guide/persistent-volumes/
##
persistence:
  enabled: true
  ## A manually managed Persistent Volume and Claim
  ## Requires persistence.enabled: true
  ## If defined, PVC must be created manually before volume will be bound
  # existingClaim:

  ## mongodb data Persistent Volume Storage Class
  ## If defined, storageClassName: <storageClass>
  ## If set to "-", storageClassName: "", which disables dynamic provisioning
  ## If undefined (the default) or set to null, no storageClassName spec is
  ##   set, choosing the default provisioner.  (gp2 on AWS, standard on
  ##   GKE, AWS & OpenStack)
  ##
  # storageClass: "-"
  accessModes:
    - ReadWriteOnce
  size: 10Gi
  annotations: {}

## Configure extra options for liveness and readiness probes
## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes)
livenessProbe:
  enabled: true
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 6
  successThreshold: 1
readinessProbe:
  enabled: true
  initialDelaySeconds: 5
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 6
  successThreshold: 1

# Entries for the MongoDB config file
configmap:
#  # Where and how to store data.
#  storage:
#    dbPath: /opt/bitnami/mongodb/data/db
#    journal:
#      enabled: true
#    #engine:
#    #wiredTiger:
#  # where to write logging data.
#  systemLog:
#    destination: file
#    logAppend: true
#    path: /opt/bitnami/mongodb/logs/mongodb.log
#  # network interfaces
#  net:
#    port: 27017
#    bindIp: 0.0.0.0
#    unixDomainSocket:
#      enabled: true
#      pathPrefix: /opt/bitnami/mongodb/tmp
#  # replica set options
#  replication:
#    replSetName: replicaset
#  # process management options
#  processManagement:
#     fork: false
#     pidFilePath: /opt/bitnami/mongodb/tmp/mongodb.pid
#  # set parameter options
#  setParameter:
#     enableLocalhostAuthBypass: true
#  # security options
#  security:
#    authorization: enabled
#    keyFile: /opt/bitnami/mongodb/conf/keyfile

## Prometheus Exporter / Metrics
##
metrics:
  enabled: true

  image:
    registry: docker.io
    repository: forekshub/percona-mongodb-exporter
    tag: latest
    pullPolicy: IfNotPresent
    ## Optionally specify an array of imagePullSecrets.
    ## Secrets must be manually created in the namespace.
    ## ref: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
    ##
    # pullSecrets:
    #   - myRegistrKeySecretName

  ## Metrics exporter resource requests and limits
  ## ref: http://kubernetes.io/docs/user-guide/compute-resources/
  ##
  # resources: {}

  ## Metrics exporter pod Annotation
  podAnnotations:
    prometheus.io/scrape: 'true'
    prometheus.io/port: '9216'

  ## Prometheus Service Monitor
  ## ref: https://github.com/coreos/prometheus-operator
  ##      https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md
  serviceMonitor:
    ## If the operator is installed in your cluster, set to true to create a Service Monitor Entry
    enabled: false
    ## Used to pass Labels that are used by the Prometheus installed in your cluster to select Service Monitors to work with
    ## ref: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#prometheusspec
    additionalLabels: {}

    ## Specify Metric Relabellings to add to the scrape endpoint
    ## ref: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#endpoint
    # relabellings:

    alerting:
      ## Define individual alerting rules as required
      ## ref: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#rulegroup
      ##      https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/
      rules: {}

      ## Used to pass Labels that are used by the Prometheus installed in your cluster to select Prometheus Rules to work with
      ## ref: https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#prometheusspec
      additionalLabels: {}

It was a problem with my resource limits. Trying to install with replicaSet disabled shows error which it didn't before.

Great @dottodot ! I'm glad you were able to identify the issue!!! Please do not hesitate to let us know if you face issues with this Helm chart again.

repo: helm/charts


text:
[stable/nginx-ingress] Updating the chart without changing nginx image version break the ingress

Describe the bug
If you update the chart without changing the Nginx image the pods stop working.
Version of Helm and Kubernetes:
K8s v1.12.7
Helm v2.14.3
Which chart:
v1.17.1
What happened:
I had Nginx-ingress installed (nginx-ingress-1.15.0, v0.24.1).
I updated the chart (nginx-ingress-1.17.1, v0.24.1).
The Nginx version was not updated by choice (due to this problem https://github.com/kubernetes/ingress-nginx/issues/4305).
The nginx pods have begun to generate these errors:
E0902 08:07:22.820980      12 reflector.go:126] k8s.io/ingress-nginx/internal/ingress/controller/store/store.go:156: Failed to list *v1.Pod: Unauthorized
E0902 08:07:22.821894      12 reflector.go:126] k8s.io/ingress-nginx/internal/ingress/controller/store/store.go:154: Failed to list *v1.Secret: Unauthorized
E0902 08:07:22.822561      12 reflector.go:126] k8s.io/ingress-nginx/internal/ingress/controller/store/store.go:153: Failed to list *v1.Service: Unauthorized
E0902 08:07:23.118202      12 reflector.go:126] k8s.io/ingress-nginx/internal/ingress/controller/store/store.go:176: Failed to list *v1beta1.Ingress: Unauthorized
E0902 08:07:23.278460      12 reflector.go:126] k8s.io/ingress-nginx/internal/ingress/controller/store/store.go:152: Failed to list *v1.Endpoints: Unauthorized
E0902 08:07:23.563842      12 reflector.go:126] k8s.io/ingress-nginx/internal/ingress/controller/store/store.go:155: Failed to list *v1.ConfigMap: Unauthorized
E0902 08:07:23.824365      12 reflector.go:126] k8s.io/ingress-nginx/internal/ingress/controller/store/store.go:156: Failed to list *v1.Pod: Unauthorized
E0902 08:07:23.824869      12 reflector.go:126] k8s.io/ingress-nginx/internal/ingress/controller/store/store.go:154: Failed to list *v1.Secret: Unauthorized
E0902 08:07:23.826023      12 reflector.go:126] k8s.io/ingress-nginx/internal/ingress/controller/store/store.go:153: Failed to list *v1.Service: Unauthorized
E0902 08:07:24.121045      12 reflector.go:126] k8s.io/ingress-nginx/internal/ingress/controller/store/store.go:176: Failed to list *v1beta1.Ingress: Unauthorized

And then I found this error in the pods:
MountVolume.SetUp failed for volume "nginx-ingress-token-2nf6f" : secrets "nginx-ingress-token-2nf6f" not found

Basically, the chart update changed the name of the secret. The pods had the old and stopped working. By restarting them they took the secret correctly and restarted to work properly.
What you expected to happen:
If I update only the chart I would like the pods to continue to work
How to reproduce it (as minimally and precisely as possible):
Redo the same step that I did.
Anything else we need to know:

@ChiefAlexander @taharah can I have feedback?
I created this ticket because stale bot closed the old one https://github.com/helm/charts/issues/16809

@ChiefAlexander @taharah 😢

https://github.com/ChiefAlexander

@ChiefAlexander @taharah 😢

@aledbf maybe you?

Moved this issue in the new chart location. https://github.com/kubernetes/ingress-nginx/issues/5559


text:
[stable/graphite] Fix missing image tag in init container spec

What this PR does / why we need it:
Graphite recently changed their initialization scripts in 1.1.5-x. The init container using :latest resulted in a failure to run the init script and a crash loop.
Checklist

[X] DCO signed
[X] Chart Version bumped
[X] Variables are documented in the README.md

/assign @fabian-schlegel
/assign @monotek

/assign @fabian-schlegel


text:
Update statefulset.yaml

What this PR does / why we need it:
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ ] DCO signed
[ ] Chart Version bumped
[ ] Variables are documented in the README.md

please sign the DCO!
/ok-to-test


text:
[stable/prometheus-blackbox-exporter] Fixes issue where containers in deployment were running as root

Signed-off-by: Angus Williams anguswilliams@gmail.com

What this PR does / why we need it:
Due the the securityContext key being duplicated in the deployment template, some of the runAsUser configuration was being ignored. This breaks the helm deployment in some k8s clusters which enforce that containers run as non-root.
Also updates the configmap-reload container to run as user 65534 as per the jimmidyson/configmap-reload Dockerfile.
Which issue this PR fixes
N/A
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign @gianrubio

Hello!
This chart will break icmp blackbox probing with podsecuritypolicy enabled clusters.

/assign desaintmartin

Thanks!
/ok-to-test
/lgtm

authors: anguswilliams desaintmartin fulii


text:
Deploy Issues after upgrading helm 2.13 to 2.14 - K8s 1.8.4

Output of helm version:
Client: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.0", GitCommit:"05811b84a3f93603dd6c2fcfe57944dfa7ab7fd0", GitTreeState:"clean"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.4", GitCommit:"9befc2b8928a9426501d3bf62f72849d5cbcd5a3", GitTreeState:"clean", BuildDate:"2017-11-20T05:28:34Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.4", GitCommit:"9befc2b8928a9426501d3bf62f72849d5cbcd5a3", GitTreeState:"clean", BuildDate:"2017-11-20T05:17:43Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.):
AWS/K8s/Kops
We use gitlab pipelines to deploy our apps, and since gitlab uses latest helm version, today it got updated and many deploys are failing (I did upgrade helm version at our cluster):
Examples:
Error: error validating "": error validating data: [ValidationError(Deployment.spec.template.spec.containers[1].ports[0]): unknown field "exec" in io.k8s.api.core.v1.ContainerPort, ValidationError(Deployment.spec.template.spec.containers[1].ports[0]): unknown field "initialDelaySeconds" in io.k8s.api.core.v1.ContainerPort]
Error: error validating "": error validating data: ValidationError(StatefulSet.spec): missing required field "serviceName" in io.k8s.api.apps.v1beta1.StatefulSetSpec Error: UPGRADE FAILED: error validating "": error validating data: ValidationError(StatefulSet.spec): missing required field "serviceName" in io.k8s.api.apps.v1beta1.StatefulSetSpec
I tried fixing our templates but still nothing, and I'm afraid that this may happen to several apps (it worked for just 1 so far).
Why is this?

See #5750

Oh, sorry, I didn't think there was an issue so quickly already, my bad. Thanks

authors: bacongobbler pulpbill

repo: helm/helm


text:
Add IngressClass to manifests to be (un)installed

What this PR does / why we need it:
closes #10643
Special notes for your reviewer:
If applicable:

[ ] this PR contains documentation
[X] this PR contains unit tests
[ ] this PR has been tested for backwards compatibility

Hi @hickeyma.  With the new "Distributed responsibility for picking" of HIP 0010, you can go ahead and cherry-pick this commit into the release-3.8 branch right away.  This will allow the release branch to be ready when it is time to cut the next maintenance release.

@marckhouzam Good idea. Cheery picked this and others that needed picking.

authors: ghost hickeyma marckhouzam


text:
Rörelsemodul

Added module "Rörelse" with subviews and admin views.
Note: Requires this branch of the app:  https://github.com/helsingborg-stad/app-laiban-ios/pull/22
Main flow:
https://user-images.githubusercontent.com/24652414/200827977-5ae9b83a-d5d9-4f9d-ba9d-06e58d73f117.mov
Admin:
https://user-images.githubusercontent.com/24652414/200828273-38db9acc-9c15-45e5-ade8-45f0373da486.mov

Missing schema when opening spm-laiban. Can't run previews.
Getting a bunch of undefined symbol errors when importing package to laiban-ios-example:

Should be resolved with latest commit!

Can't get past parental view.
User input disabled in parental view when running Laiban on hardware iPhone Xr iOS  16.1 and iPad Pro 12.9 (fifth gen) iOS 15.4.1.
Works fine when testing with simulator.

Can't get past parental view. User input disabled in parental view when running Laiban on hardware iPhone Xr iOS 16.1 and iPad Pro 12.9 (fifth gen) iOS 15.4.1.
Works fine when testing with simulator.

Hm, strange error. I've tried with two (different kind of) physical devices and can't reproduce it. I will investigate further on monday!

The parental becomes permanently deactivated after a successful login.
Would It be possible to always keep the parental gate active for views where the user can update values?

The parental becomes permanently deactivated after a successful login. Would It be possible to always keep the parental gate active for views where the user can update values?

The parental gate is now shown every time a new activity will be registered.

authors: fredrikhaggbom zilaei

repo: helsingborg-stad/spm-laiban


text:
Birthday party wish

Nice 👍

Bro it's not working

repo: hemantapkh/PyBirthdayWish


text:
add settings to the Settings > Extensions GUI

After you generate and modify the config file, there is no way to get back to it to see it or modify it. The only thing I can find is to 'generate' the file again but that overwrites everything. Very frustrating.

Hi, for now, the extension support only local config file (.vscode/pro-deployer.json). In the future, I will think about global settings, that will be edited from settings UI.

authors: JustinWebDev heminei

repo: heminei/vscode-pro-deployer


text:
Remove broken links (#222)

Remove invalid (not exists) telegram group (#222)

Coderjs
Trading Bitcoin
Bengkel KMB
Aceh InfoTech
Lombok Developer Meetup
W3ID - WWWID PWA
Slackware Indonesia
Mac OS X ID
MIKROTIK INDONESIA
Developer Muda Unity

CMIIW


text:
Docker vs Ephemeral Stacks

Possible Title: The case against docker?

Ephemeral Stacks vs Localstack & Docker, Pros and Cons
Show example for review apps for apis (so far we only have an article for frontend review apps)
Review Apps in AWS can easily be forwarded to PMs and commented
Peace of mind, simplicity: Ephemeral stacks are easy
Cons

Docker: relative maintenance effort

https://theburningmonk.com/2019/09/why-you-should-use-temporary-stacks-when-you-do-serverless/
https://theburningmonk.com/2023/02/how-to-handle-serverful-resources-when-using-ephemeral-environments/
https://theburningmonk.com/2022/05/my-testing-strategy-for-serverless-applications

authors: flyck hendriknielaender

repo: hendriknielaender/double-trouble


text:
running it locally

how can i run this (with the dlc version) locally? my internet goes out a lot. rain world is my goto game for when i'm forced to be offline, but the map link only works online

This repo is for the 1.5 version of the game. It's still accurate without the DLC active.
If you're looking for the version with the DLC on, it's over at https://github.com/rain-world-map/

i'm actually hoping to host it locally - the online version for both works just fine when i'm online xD (although it'd be neat to have an offline version of the DLC one)

authors: eksynn henpemaz

repo: henpemaz/Rain-World-Interactive-Map


text:
Theme breaks tab background

After installing theme through hpm and hitting Cmd+Shft+R (Full reload), everything seems fine. However, after quitting Hyper, and firing it up again, tabs are transparent.

HyperTerm keeps changing a lot with every update and it just pushed and update that broke the theme.
I'll fix it with an update asap. ✌

Just pushed an update that should fix every issue. Let me know if I've missed something. 👋

@henrikdahl I just install it and I have the same error. Last version of Hyper, and this plugins used :
  plugins: [
    "hyperterm-1password",
    "hyperterm-tab-icons",
    "hyperterm-alternatescroll",
    "hyperlinks",
    "hyper-statusline",
    "hyperterm-base16-ocean-saturated"
  ],

Thank you for your work !

@Florian95 Try commenting out the theme and launch Hyper, then uncomment it and launch Hyper again. Does it solve it?
Otherwise, what's your Hyper version and OS?

It's good only in the same window where I uncomment the theme. If I launch a new one, nothing...
MacOS 10.12.1
Hyper 1.0.1 (1.0.1.1369)

@henrikdahl Any news about this bug ? How can I help ?
Thank you.

@Florian95 sorry, didn't know it was still an issue.
What's your plugin list? ✌

  plugins: [
    "hyperterm-1password",
    "hyperterm-tab-icons",
    "hyperterm-alternatescroll",
    "hyperlinks",
    "hyperterm-base16-ocean-saturated"
  ],

@Florian95
Name was changed to hyper-oceans16 to match the new plugin naming convention of Hyper. Additionally the tabs were separated into its own plugin for the ability to use them with any theme https://github.com/henrikdahl/hyper-tabs-enhanced
Would you mind trying these to see if it solves it for you? ✌

authors: Florian95 henrikdahl kliptonize


text:
WPGraphQl Yoast SEO Plugin

Adding WPGraphQl Yoast SEO Plugin to list of plugins.

@ashhitch thanks for the contribution. Glad to have it in the list.

authors: ashhitch henrikwirth

repo: henrikwirth/awesome-wordpress-gatsby


text:
using should be lowercase

This was causing the error with Travis.

@simonbyrne Thank you, I am going to adjust I think they are communicating now

@simonbyrne python paths still don't match.

I don't think the paths need to match. At least that is not the cause of the tests failing. The cause of the tests failing is that it cannot find a dataset named "Iris". Perhaps check that the name is correct?

authors: henrykironde simonbyrne


text:
Implement Secret Discovery Service

Implement Secret Discovery Service in Contour.
This enhancement request came out of the discussion on #862 for supporting rotating and invalidating certificates using SDS. More info about SDS is available here: https://www.envoyproxy.io/docs/envoy/latest/configuration/secret.

@vaamarnath we have a requirement to have SDS implementation in contour as well. Do you have a design that you can share with the details ?

@khgandhi The current requirement for SDS came in through #862. There is no design available for this issue at this point in time.
\cc @davecheney

@davecheney I have created an initial design draft for SDS support. Can you please take a look.

Due to the need to ship Contour 0.11 to address a security issue in Envoy 1.9.0 this has been bumped to the 0.12 milestone.

With #901 falling off the 0.12 milestone @vaamarnath and I have talked and the plan is to implement the basic SDS plumbing and we'll revisit the integration points with the rest of Contour later.
I was going to sit down and write down the steps to add SDS to internal/grpc but it turns out we already have 99% of the design from @bmadhavan in #960. I've polished that up and you can find here.
I'm not going to mark this issue as 0.12 as @vaamarnath nor I can commit to taking this one by the 0.12 deadline, but consider the design for adding SDS up for grabs.
Note to implementors: please work incrementally, one PR per high level design point. Please don't send one giant ass PR for the whole thing, that's not cool. You should also add some tests to internal/e2e which are really the func tests of internal/grpc.
Thanks
Dave

@vaamarnath @davecheney Thanks for the notes.  I've been building up the full solution over the last few days, adding tests, and verifying functionality.  I'll split up the change set into a few PRs, mirroring the suggestion to provide 1 per major design point.

I think this issue is now complete, at least wrt. the 0.12 milestone. Thank you to @vaamarnath @mattalberts and @stevesloka for pushing this forward.

authors: bmadhavan davecheney khgandhi mattalberts vaamarnath

repo: heptio/contour


text:
internal/dag: Fixed route status not setting from within an HTTPProxy

A new status writer was getting passed to processRoutes, but there was no Commit(), so status wasn't getting set back to the object in the API.
Signed-off-by: Steve Sloka slokas@vmware.com

@stevesloka please rebase and try again. I landed a bunch of PRs this afternoon which I hope will fix the shoddy status api I wrote. I think it should be a bit easier to use now.

authors: davecheney stevesloka


text:
Episode Idea: kube-ingress-aws-controller

its like my secret weapon in AWS when it comes to:

ssl offloading
ingress (skipper, comes bundled in)
many more
handling dns entries (when external dns is installed)

see: https://github.com/zalando-incubator/kube-ingress-aws-controller

cc @szandala

would love to see this.

authors: HerrmannHinz jrake-revelant

repo: heptio/tgik


text:
self-sign certificate?

How to solve a problem with self-sign certificate?
Post https://dex.k8s.example.com/token: x509: certificate signed by unknown authority

Hey @rlagutinhub which step in the process do you get that error? The flow should look like this:

Click "Login" from Gangway
Redirect to Dex
Redirect to Identity Provider (e.x. Google)
Redirect back to Gangway

Redirect to Dex

You could look to set the trusted-ca config param (https://github.com/heptiolabs/gangway/blob/master/cmd/gangway/config.go#L46:2).

with TrustedCAPath param not work
My current config gangway:
apiVersion: v1
kind: ConfigMap
metadata:
name: gangway
namespace: gangway
data:
gangway.yaml: |
# The address to listen on. Defaults to 0.0.0.0 to listen on all interfaces.
# Env var: GANGWAY_HOST
# host: 0.0.0.0
# The port to listen on. Defaults to 8080.
# Env var: GANGWAY_PORT
# port: 8080

# Should Gangway serve TLS vs. plain HTTP? Default: false
# Env var: GANGWAY_SERVE_TLS
# serveTLS: false

# The public cert file (including root and intermediates) to use when serving
# TLS.
# Env var: GANGWAY_CERT_FILE
# certFile: /etc/gangway/tls/tls.crt

# The private key file when serving TLS.
# Env var: GANGWAY_KEY_FILE
# keyFile: /etc/gangway/tls/tls.key

TrustedCAPath: /etc/gangway/tls/ca.pem

# The cluster name. Used in UI and kubectl config instructions.
# Env var: GANGWAY_CLUSTER_NAME
# clusterName: "${GANGWAY_CLUSTER_NAME}"
clusterName: "MTA4RU"

# OAuth2 URL to start authorization flow.
# Env var: GANGWAY_AUTHORIZE_URL
# authorizeURL: "https://${DNS_NAME}/authorize"
authorizeURL: "https://dex.k8s.dev.mta4.ru/auth"

# OAuth2 URL to obtain access tokens.
# Env var: GANGWAY_TOKEN_URL
# tokenURL: "https://${DNS_NAME}/oauth/token"
tokenURL: "https://dex.k8s.dev.mta4.ru/token"

# Endpoint that provides user profile information [optional]. Not all providers
# will require this.
# Env var: GANGWAY_AUDIENCE
# audience: "https://${DNS_NAME}/userinfo"

# Used to specify the scope of the requested Oauth authorization.
# scopes: ["openid", "profile", "email", "offline_access"]
scopes: ["openid", "profile", "email", "offline_access"]

# Where to redirect back to. This should be a URL where gangway is reachable.
# Typically this also needs to be registered as part of the oauth application
# with the oAuth provider.
# Env var: GANGWAY_REDIRECT_URL
# redirectURL: "https://${GANGWAY_REDIRECT_URL}/callback"
redirectURL: "https://gangway.k8s.dev.mta4.ru/callback"

# API client ID as indicated by the identity provider
# Env var: GANGWAY_CLIENT_ID
# clientID: "${GANGWAY_CLIENT_ID}"
clientID: "gangway"

# API client secret as indicated by the identity provider
# Env var: GANGWAY_CLIENT_SECRET
# clientSecret: "${GANGWAY_CLIENT_SECRET}"
clientSecret: "UncOnocvsJ5mT2FCX6oimZahAJkCtlUHa/a1zqs/gPo="

# The JWT claim to use as the username. This is used in UI.
# Default is "nickname".
# Env var: GANGWAY_USERNAME_CLAIM
# usernameClaim: "sub"
usernameClaim: "email"

# The JWT claim to use as the email claim. This is used to name the
# "user" part of the config. Default is "email".
# Env var: GANGWAY_EMAIL_CLAIM
emailClaim: "email"

# The API server endpoint used to configure kubectl
# Env var: GANGWAY_APISERVER_URL
# apiServerURL: "https://${GANGWAY_APISERVER_URL}"
apiServerURL: "https://cluster.example.com"

# The path to find the CA bundle for the API server. Used to configure kubectl.
# This is typically mounted into the default location for workloads running on
# a Kubernetes cluster and doesn't need to be set.
# Env var: GANGWAY_CLUSTER_CA_PATH
# cluster_ca_path: "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"

# The path gangway uses to create urls (defaults to "")
# Env var: GANGWAY_HTTP_PATH
#httpPath: "https://${GANGWAY_HTTP_PATH}"

Current gangway deployment:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: gangway
namespace: gangway
labels:
app: gangway
spec:
replicas: 1
selector:
matchLabels:
app: gangway
strategy:
template:
metadata:
labels:
app: gangway
revision: "1"
spec:
containers:
- name: gangway
image: gcr.io/heptio-images/gangway:v2.2.0
imagePullPolicy: Always
command: ["gangway", "-config", "/gangway/gangway.yaml"]
env:
- name: GANGWAY_SESSION_SECURITY_KEY
valueFrom:
secretKeyRef:
name: gangway-key
key: sesssionkey
ports:
- name: http
containerPort: 8080
protocol: TCP
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "200m"
memory: "512Mi"
volumeMounts:
- name: gangway
mountPath: /gangway/
- name: ca
mountPath: /etc/gangway/tls/
livenessProbe:
httpGet:
path: /
port: 8080
initialDelaySeconds: 20
timeoutSeconds: 1
periodSeconds: 60
failureThreshold: 3
readinessProbe:
httpGet:
path: /
port: 8080
timeoutSeconds: 1
periodSeconds: 10
failureThreshold: 3
volumes:
- name: gangway
configMap:
name: gangway
- name: ca
configMap:
name: ca
items:
- key: ca.pem
path: ca.pem
Log auth dex:
time="2018-10-25T22:57:13Z" level=info msg="config using log level: debug"
time="2018-10-25T22:57:13Z" level=info msg="config issuer: https://dex.k8s.dev.mta4.ru/"
time="2018-10-25T22:57:13Z" level=info msg="kubernetes client apiVersion = dex.coreos.com/v1"
time="2018-10-25T22:57:13Z" level=info msg="creating custom Kubernetes resources"
time="2018-10-25T22:57:13Z" level=info msg="custom resource already created authcodes.dex.coreos.com"
time="2018-10-25T22:57:13Z" level=info msg="custom resource already created authrequests.dex.coreos.com"
time="2018-10-25T22:57:13Z" level=info msg="custom resource already created oauth2clients.dex.coreos.com"
time="2018-10-25T22:57:13Z" level=info msg="custom resource already created signingkeies.dex.coreos.com"
time="2018-10-25T22:57:13Z" level=info msg="custom resource already created refreshtokens.dex.coreos.com"
time="2018-10-25T22:57:13Z" level=info msg="custom resource already created passwords.dex.coreos.com"
time="2018-10-25T22:57:13Z" level=info msg="custom resource already created offlinesessionses.dex.coreos.com"
time="2018-10-25T22:57:13Z" level=info msg="custom resource already created connectors.dex.coreos.com"
time="2018-10-25T22:57:13Z" level=info msg="config storage: kubernetes"
time="2018-10-25T22:57:13Z" level=info msg="config static client: gangway"
time="2018-10-25T22:57:13Z" level=info msg="config connector: ldap"
time="2018-10-25T22:57:13Z" level=info msg="config skipping approval screen"
time="2018-10-25T22:57:13Z" level=info msg="listening (http/telemetry) on 0.0.0.0:5558"
time="2018-10-25T22:57:13Z" level=info msg="listening (http) on 0.0.0.0:5556"
time="2018-10-25T23:00:46Z" level=info msg="performing ldap search OU=k8s,DC=dev,DC=mta4,DC=ru sub (&(objectClass=person)(sAMAccountName=user1))" connector=LDAP
time="2018-10-25T23:00:46Z" level=info msg="username "user1" mapped to entry CN=user1,OU=k8s,DC=dev,DC=mta4,DC=ru" connector=LDAP
time="2018-10-25T23:00:46Z" level=error msg="ldap: invalid password for user "CN=user1,OU=k8s,DC=dev,DC=mta4,DC=ru"" connector=LDAP
time="2018-10-25T23:01:04Z" level=info msg="performing ldap search OU=k8s,DC=dev,DC=mta4,DC=ru sub (&(objectClass=person)(sAMAccountName=user1))" connector=LDAP
time="2018-10-25T23:01:04Z" level=info msg="username "user1" mapped to entry CN=user1,OU=k8s,DC=dev,DC=mta4,DC=ru" connector=LDAP
time="2018-10-25T23:01:04Z" level=error msg="Failed to login user: ldap: entry "CN=user1,OU=k8s,DC=dev,DC=mta4,DC=ru" missing following required attribute(s): ["mail"]"
time="2018-10-25T23:01:54Z" level=info msg="performing ldap search OU=k8s,DC=dev,DC=mta4,DC=ru sub (&(objectClass=person)(sAMAccountName=user1))" connector=LDAP
time="2018-10-25T23:01:54Z" level=info msg="username "user1" mapped to entry CN=user1,OU=k8s,DC=dev,DC=mta4,DC=ru" connector=LDAP
time="2018-10-25T23:01:54Z" level=info msg="login successful: connector "ldap", username="user1", email="user1@dev.mta4.ru", groups=[]"
Log auth gangway:
time="2018-10-25T23:07:16Z" level=info msg="GET / 10.244.2.0:45312"
time="2018-10-25T23:07:17Z" level=info msg="GET /js/materialize.js 10.244.2.0:45312"
time="2018-10-25T23:07:17Z" level=info msg="GET /js/init.js 10.244.2.0:45314"
time="2018-10-25T23:07:26Z" level=info msg="GET / 10.244.1.1:36756"
time="2018-10-25T23:07:27Z" level=info msg="GET / 10.244.1.1:36758"
time="2018-10-25T23:07:36Z" level=info msg="GET / 10.244.1.1:36760"
time="2018-10-25T23:07:46Z" level=info msg="GET / 10.244.1.1:36762"
time="2018-10-25T23:07:56Z" level=info msg="GET / 10.244.1.1:36764"
time="2018-10-25T23:08:02Z" level=info msg="GET /login 10.244.2.0:45352"
time="2018-10-25T23:08:06Z" level=info msg="GET / 10.244.1.1:36766"
time="2018-10-25T23:08:13Z" level=info msg="GET /callback?code=mk62mmbmmarfvv7lple7smd36&state=HmaKW98sf8SERZLSVyvNBmjS1sUvUFTi0INr%2BExxdMs%3D 10.244.2.0:45366"
time="2018-10-25T23:08:16Z" level=info msg="GET / 10.244.1.1:36772"
My self-sign cert script example:
#!/bin/bash
mkdir -p ssl
cat << EOF > ssl/req.cnf
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[v3_req]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = dex.k8s.dev.mta4.ru
DNS.2 = login.k8s.dev.mta4.ru
DNS.3 = gangway.k8s.dev.mta4.ru
EOF
openssl genrsa -out ssl/ca-key.pem 2048
openssl req -x509 -new -nodes -key ssl/ca-key.pem -days 3650 -out ssl/ca.pem -subj "/CN=kube-oidc-auth-ca"
openssl genrsa -out ssl/dex.k8s.dev.mta4.ru-key.pem 2048
openssl req -new -key ssl/dex.k8s.dev.mta4.ru-key.pem -out ssl/dex.k8s.dev.mta4.ru.csr -subj "/CN=dex.k8s.dev.mta4.ru" -config ssl/req.cnf
openssl x509 -req -in ssl/dex.k8s.dev.mta4.ru.csr -CA ssl/ca.pem -CAkey ssl/ca-key.pem -CAcreateserial -out ssl/dex.k8s.dev.mta4.ru.pem -days 3650 -extensions v3_req -extfile ssl/req.cnf
openssl genrsa -out ssl/gangway.k8s.dev.mta4.ru-key.pem 2048
openssl req -new -key ssl/gangway.k8s.dev.mta4.ru-key.pem -out ssl/gangway.k8s.dev.mta4.ru.csr -subj "/CN=gangway.k8s.dev.mta4.ru" -config ssl/req.cnf
openssl x509 -req -in ssl/gangway.k8s.dev.mta4.ru.csr -CA ssl/ca.pem -CAkey ssl/ca-key.pem -CAcreateserial -out ssl/gangway.k8s.dev.mta4.ru.pem -days 3650 -extensions v3_req -extfile ssl/req.cnf
kubectl create secret tls dex.k8s.dev.mta4.ru.tls --cert=ssl/dex.k8s.dev.mta4.ru.pem --key=ssl/dex.k8s.dev.mta4.ru-key.pem -n dex
kubectl create secret tls gangway.k8s.dev.mta4.ru.tls --cert=ssl/gangway.k8s.dev.mta4.ru.pem --key=ssl/gangway.k8s.dev.mta4.ru-key.pem -n gangway

It worked for me, after recreate custom docker image:

There is a possibility without creating custom docker image?

Had the same problem with self-signed certs. Setting the below property worked for me on k8s.
trustedCAPath: "/var/run/secrets/kubernetes.io/serviceaccount/ca.crt"

@rlagutinhub can you try again and update your config file from: TrustedCAPath to trustedCAPath? The yaml parsing is case sensitive and my guess is when you set this param, it didn't get parsed and wasn't set.
When you load that config item up, it should be added to teh root ca's like you did when adding via the dockerfile: https://github.com/heptiolabs/gangway/blob/master/internal/config/transport.go#L44

yes it works)
Another problem
oidc via ldap+dex - invalid bearer token, invalid bearer token https://github.com/kubernetes/kubernetes/issues/70601

Another problem
oidc via ldap+dex - invalid bearer token, invalid bearer token
kubernetes/kubernetes#70601
dexidp/dex#1336

It is very possible that reason for error [invalid bearer token, [invalid bearer token, invalid bearer token]] ,
what I do backup manifest kube-api config file before changing it
cp -p /etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/manifests/kube-apiserver.yaml.orig

really), after deleting this backup file /etc/kubernetes/manifests/kube-apiserver.yaml.orig
it works
for information https://github.com/dexidp/dex/issues/1336

Hi, I'm having the same problem but can't get to solve it with the information above.
My current configMap and deployment are:
apiVersion: v1
kind: ConfigMap
metadata:
  name: gangway
  namespace: auth-system
data:
  gangway.yaml: |
    clusterName: "K8S"
    apiServerURL: "https://10.64.160.231:6443"
    authorizeURL: "https://auth.kubernetes.domain.net/auth"
    tokenURL: "https://auth.kubernetes.domain.net/token"
    clientID: "oidc-auth-client"
    clientSecret: "*******************"
    redirectURL: "https://kubectl.kubernetes.domain.net/callback"
    scopes: ["openid", "profile", "email", "offline_access"]
    usernameClaim: "email"
    emailClaim: "email"
    trustedCAPath: "/cacerts/tls.crt"

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: gangway
  namespace: auth-system
  labels:
    app: gangway
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gangway
  strategy:
  template:
    metadata:
      labels:
        app: gangway
        revision: "1"
    spec:
      containers:
        - name: gangway
          image: gcr.io/heptio-images/gangway:v2.0.0
          imagePullPolicy: Always
          command: ["gangway", "-config", "/gangway/gangway.yaml"]
          env:
            - name: GANGWAY_SESSION_SECURITY_KEY
              valueFrom:
                secretKeyRef:
                  name: gangway-key
                  key: sesssionkey
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
          resources:
            requests:
              cpu: "100m"
              memory: "100Mi"
            limits:
              cpu: "100m"
              memory: "100Mi"
          volumeMounts:
            - name: gangway
              mountPath: /gangway/
            - name: ca
              mountPath: /cacerts/
          livenessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 20
            timeoutSeconds: 1
            periodSeconds: 60
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /
              port: 8080
            timeoutSeconds: 1
            periodSeconds: 10
            failureThreshold: 3
      volumes:
        - name: gangway
          configMap:
            name: gangway
        - name: ca
          secret:
            secretName: rootca

And the secret rootca was creating using:
For the root certificate:
openssl genrsa -des3 -out rootCA.key 4096
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt
kubectl create secret tls rootCA --key rootCA.key --cert rootCA.crt --namespace auth-system
For creating the certificates I followed the following steps:
For the certificate used when loading gangway:
openssl genrsa -out auth.kubernetes.domain.net.key 2048
openssl req -new -sha256 -key auth.kubernetes.domain.net -subj "/C=US/ST=CA/O=MyOrg, Inc./CN=auth.kubernetes.domain.net" -out auth.kubernetes.domain.net.csr
openssl x509 -req -in auth.kubernetes.domain.net.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out auth.kubernetes.domain.net.crt -days 500 -sha256
kubectl create secret tls auth.kubernetes.domain.net --key auth.kubernetes.domain.net.key --cert auth.kubernetes.domain.net.crt
Which is used in the following daemonset (I have a nginx daemonset in the nodes so I don't use Ingress):
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet
      containers:
      - image: nginx:1.15.3-alpine
        name: nginx
        ports:
        - name: http
          containerPort: 80
          hostPort: 80
        - name: https
          containerPort: 443
          hostPort: 443
        volumeMounts:
        - name: "config"
          mountPath: "/etc/nginx"
        - name: secret-volume
          mountPath: /etc/nginx/ssl
      volumes:
      - name: config
        configMap:
          name: nginx-conf
      - name: secret-volume
        secret:
           secretName: auth.kubernetes.domain.net

---

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-conf
data:
  nginx.conf: |
    worker_processes 1;
    error_log /dev/stdout info;

    events {
      worker_connections 10;
    }

    http {
      access_log /dev/stdout;

      server {
        listen 443 ssl;
        server_name auth.kubernetes.domain.net;
        ssl_certificate /etc/nginx/ssl/tls.crt;
        ssl_certificate_key /etc/nginx/ssl/tls.key;

        location / {
          proxy_pass http://dex.auth-system.svc.cluster.local:5556;
        }
      }
      server {
        server_name kubectl.kubernetes.domain.net
        ssl_certificate /etc/nginx/ssl/tls.crt;
        ssl_certificate_key /etc/nginx/ssl/tls.key;
        listen 443 ssl;
        #listen 80;
        location / {
          proxy_pass http://gangway-svc.auth-system.svc.cluster.local:80;
        }
      }
   }

Hi @stevesloka
Could you tell me which cert that I should choose from the certificate chain attached to my dex domain for the configuration option "trustedCACert" of Gangway?
My dex pod runs in a kubernetes cluster, which has tls enabled. however, the service for my dex runs behind my AWS ALB (application load balancer) which has a well-known certificate attached to. And my AWS ALB terminates the HTTP request from my gangway.
Now, upon checking the well-known certificate attached to my ALB, it turned out that the certificate attached to my ALB was a certificate chain (see the certificate chain below) instead of a single cert. In this case, among the 4 certificates in my certificate chain, which one should I choose for the "trustedCACert" configuration option of Gangway?
Certificate chain
0 s:/CN=*.dev.tinasuper.com
i:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
-----BEGIN CERTIFICATE-----
MIIFbjCCBFagAwIBAgIQDJ8UlN9ykJiXDZ8q+STVoDANBgkqhkiG9w0BAQsFADBG
MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRUwEwYDVQQLEwxTZXJ2ZXIg
Q0EgMUIxDzANBgNVBAMTBkFtYXpvbjAeFw0xOTEyMTkwMDAwMDBaFw0yMTAxMTkx
MjAwMDBaMB4xHDAaBgNVBAMMEyouZGV2LnRpbmFzdXBlci5jb20wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCslmuiNYm5l0xh5WwReCDbVRHBOvrgCu+L
d619xq4EWX+blw7aYk1nOndVu90hxCLUgllwCgLOn9oS9Lm8VMIDXwQj505qRv9R
Vc+3W2OtM02oYxjliHKCFWMpmbI7lGaey1nBQVe9XaUTZqUQUoNtfdyXSBEd978k
fKD34axb7eTMkS3hOc+DNNGzCsg2IQfawYMuvaYzU5uJfWdS/gJFrT/JjY8YS2Yr
qsSlVUay7gaoO1GJhCl1aaxD/s9s3lDeGAaXCEDCG6bne7g1JLX/7FvheELNhrww
4DgzpahwOY00iECj6XXFjVtpOP2gprrNxF2r7sGPz7nMMmjvhZjtAgMBAAGjggJ+
MIICejAfBgNVHSMEGDAWgBRZpGYGUqB7lZI8o5QHJ5Z0W/k90DAdBgNVHQ4EFgQU
jXBoewOSSrB2FXGtdR0xqfylTegwHgYDVR0RBBcwFYITKi5kZXYudGluYXN1cGVy
LmNvbTAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9jcmwuc2NhMWIuYW1hem9udHJ1
c3QuY29tL3NjYTFiLmNybDAgBgNVHSAEGTAXMAsGCWCGSAGG/WwBAjAIBgZngQwB
AgEwdQYIKwYBBQUHAQEEaTBnMC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5zY2Ex
Yi5hbWF6b250cnVzdC5jb20wNgYIKwYBBQUHMAKGKmh0dHA6Ly9jcnQuc2NhMWIu
YW1hem9udHJ1c3QuY29tL3NjYTFiLmNydDAMBgNVHRMBAf8EAjAAMIIBAwYKKwYB
BAHWeQIEAgSB9ASB8QDvAHUApLkJkLQYWBSHuxOizGdwCjw1mAT5G9+443fNDsgN
3BAAAAFvG43s7wAABAMARjBEAiA8bO4U69vR9zxW83WDtS73PO/KGvC9bXhu5oFF
fNc9ggIgbwiiqyseH6v4m12Bu/giMN0j4P96pXS6QYO4o0tvfEUAdgCHdb/nWXz4
jEOZX73zbv9WjUdWNv9KtWDBtOr/XqCDDwAAAW8bje2NAAAEAwBHMEUCIFRF5Z7r
y6EeXO/uXUIAqvlJQgOJ8wY6Yr0QUKCGs+7zAiEAwWXwSINKpmrUMchywMCmkfcq
oA0ks5RwFan5YwNLJTcwDQYJKoZIhvcNAQELBQADggEBAGS+lfTLxP7SP5Rc9ItU
FQiNv7C5KIpH7IqnxYd6Ghy2TQPqEsynkH/3i4Db8BJQt/fEXCR07/JMC13Xcqk7
HaiIgT8Rnwr6xN6nZceAujXltdE87BTQK1uuWx1p+9i5VKZrH3rocTVm97cbmtly
pbpxolwTsYhiTJuybx71AjH1EHH9m4yMVb6lG4rpskGWnK8e89CElPkyjLJDAdv7
VnqhmVZAEzDwUTqv/uXdovV/JmBZWUbuhi3uws/VJAwn/kSf39XVLm1XtlxZYBIp
uyveUvA8TEFXagpJ9n10yyxsDMWUIi0bbjJfuNNOdwEgSxsRn+vP+krD7OsnRD+b
XrE=
-----END CERTIFICATE-----
1 s:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
i:/C=US/O=Amazon/CN=Amazon Root CA 1
-----BEGIN CERTIFICATE-----
MIIESTCCAzGgAwIBAgITBn+UV4WH6Kx33rJTMlu8mYtWDTANBgkqhkiG9w0BAQsF
ADA5MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRkwFwYDVQQDExBBbWF6
b24gUm9vdCBDQSAxMB4XDTE1MTAyMjAwMDAwMFoXDTI1MTAxOTAwMDAwMFowRjEL
MAkGA1UEBhMCVVMxDzANBgNVBAoTBkFtYXpvbjEVMBMGA1UECxMMU2VydmVyIENB
IDFCMQ8wDQYDVQQDEwZBbWF6b24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDCThZn3c68asg3Wuw6MLAd5tES6BIoSMzoKcG5blPVo+sDORrMd4f2AbnZ
cMzPa43j4wNxhplty6aUKk4T1qe9BOwKFjwK6zmxxLVYo7bHViXsPlJ6qOMpFge5
blDP+18x+B26A0piiQOuPkfyDyeR4xQghfj66Yo19V+emU3nazfvpFA+ROz6WoVm
B5x+F2pV8xeKNR7u6azDdU5YVX1TawprmxRC1+WsAYmz6qP+z8ArDITC2FMVy2fw
0IjKOtEXc/VfmtTFch5+AfGYMGMqqvJ6LcXiAhqG5TI+Dr0RtM88k+8XUBCeQ8IG
KuANaL7TiItKZYxK1MMuTJtV9IblAgMBAAGjggE7MIIBNzASBgNVHRMBAf8ECDAG
AQH/AgEAMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUWaRmBlKge5WSPKOUByeW
dFv5PdAwHwYDVR0jBBgwFoAUhBjMhTTsvAyUlC4IWZzHshBOCggwewYIKwYBBQUH
AQEEbzBtMC8GCCsGAQUFBzABhiNodHRwOi8vb2NzcC5yb290Y2ExLmFtYXpvbnRy
dXN0LmNvbTA6BggrBgEFBQcwAoYuaHR0cDovL2NydC5yb290Y2ExLmFtYXpvbnRy
dXN0LmNvbS9yb290Y2ExLmNlcjA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3Js
LnJvb3RjYTEuYW1hem9udHJ1c3QuY29tL3Jvb3RjYTEuY3JsMBMGA1UdIAQMMAow
CAYGZ4EMAQIBMA0GCSqGSIb3DQEBCwUAA4IBAQCFkr41u3nPo4FCHOTjY3NTOVI1
59Gt/a6ZiqyJEi+752+a1U5y6iAwYfmXss2lJwJFqMp2PphKg5625kXg8kP2CN5t
6G7bMQcT8C8xDZNtYTd7WPD8UZiRKAJPBXa30/AbwuZe0GaFEQ8ugcYQgSn+IGBI
8/LwhBNTZTUVEWuCUUBVV18YtbAiPq3yXqMB48Oz+ctBWuZSkbvkNodPLamkB2g1
upRyzQ7qDn1X8nn8N8V7YJ6y68AtkHcNSRAnpTitxBKjtKPISLMVCx7i4hncxHZS
yLyKQXhw2W2Xs0qLeC1etA+jTGDK4UfLeC0SF7FSi8o5LL21L8IzApar2pR/
-----END CERTIFICATE-----
2 s:/C=US/O=Amazon/CN=Amazon Root CA 1
i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgITBn+USionzfP6wq4rAfkI7rnExjANBgkqhkiG9w0BAQsF
ADCBmDELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNj
b3R0c2RhbGUxJTAjBgNVBAoTHFN0YXJmaWVsZCBUZWNobm9sb2dpZXMsIEluYy4x
OzA5BgNVBAMTMlN0YXJmaWVsZCBTZXJ2aWNlcyBSb290IENlcnRpZmljYXRlIEF1
dGhvcml0eSAtIEcyMB4XDTE1MDUyNTEyMDAwMFoXDTM3MTIzMTAxMDAwMFowOTEL
MAkGA1UEBhMCVVMxDzANBgNVBAoTBkFtYXpvbjEZMBcGA1UEAxMQQW1hem9uIFJv
b3QgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALJ4gHHKeNXj
ca9HgFB0fW7Y14h29Jlo91ghYPl0hAEvrAIthtOgQ3pOsqTQNroBvo3bSMgHFzZM
9O6II8c+6zf1tRn4SWiw3te5djgdYZ6k/oI2peVKVuRF4fn9tBb6dNqcmzU5L/qw
IFAGbHrQgLKm+a/sRxmPUDgH3KKHOVj4utWp+UhnMJbulHheb4mjUcAwhmahRWa6
VOujw5H5SNz/0egwLX0tdHA114gk957EWW67c4cX8jJGKLhD+rcdqsq08p8kDi1L
93FcXmn/6pUCyziKrlA4b9v7LWIbxcceVOF34GfID5yHI9Y/QCB/IIDEgEw+OyQm
jgSubJrIqg0CAwEAAaOCATEwggEtMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/
BAQDAgGGMB0GA1UdDgQWBBSEGMyFNOy8DJSULghZnMeyEE4KCDAfBgNVHSMEGDAW
gBScXwDfqgHXMCs4iKK4bUqc8hGRgzB4BggrBgEFBQcBAQRsMGowLgYIKwYBBQUH
MAGGImh0dHA6Ly9vY3NwLnJvb3RnMi5hbWF6b250cnVzdC5jb20wOAYIKwYBBQUH
MAKGLGh0dHA6Ly9jcnQucm9vdGcyLmFtYXpvbnRydXN0LmNvbS9yb290ZzIuY2Vy
MD0GA1UdHwQ2MDQwMqAwoC6GLGh0dHA6Ly9jcmwucm9vdGcyLmFtYXpvbnRydXN0
LmNvbS9yb290ZzIuY3JsMBEGA1UdIAQKMAgwBgYEVR0gADANBgkqhkiG9w0BAQsF
AAOCAQEAYjdCXLwQtT6LLOkMm2xF4gcAevnFWAu5CIw+7bMlPLVvUOTNNWqnkzSW
MiGpSESrnO09tKpzbeR/FoCJbM8oAxiDR3mjEH4wW6w7sGDgd9QIpuEdfF7Au/ma
eyKdpwAJfqxGF4PcnCZXmTA5YpaP7dreqsXMGz7KQ2hsVxa81Q4gLv7/wmpdLqBK
bRRYh5TmOTFffHPLkIhqhBGWJ6bt2YFGpn6jcgAKUj6DiAdjd4lpFw85hdKrCEVN
0FE6/V1dN2RMfjCyVSRCnTawXZwXgWHxyvkQAiSr6w10kY17RSlQOYiypok1JR4U
akcjMS9cmvqtmg5iUaQqqcT5NJ0hGA==
-----END CERTIFICATE-----
3 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
-----BEGIN CERTIFICATE-----
MIIEdTCCA12gAwIBAgIJAKcOSkw0grd/MA0GCSqGSIb3DQEBCwUAMGgxCzAJBgNV
BAYTAlVTMSUwIwYDVQQKExxTdGFyZmllbGQgVGVjaG5vbG9naWVzLCBJbmMuMTIw
MAYDVQQLEylTdGFyZmllbGQgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTAeFw0wOTA5MDIwMDAwMDBaFw0zNDA2MjgxNzM5MTZaMIGYMQswCQYDVQQGEwJV
UzEQMA4GA1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTElMCMGA1UE
ChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjE7MDkGA1UEAxMyU3RhcmZp
ZWxkIFNlcnZpY2VzIFJvb3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVDDrEKvlO4vW+GZdfjohTsR8/
y8+fIBNtKTrID30892t2OGPZNmCom15cAICyL1l/9of5JUOG52kbUpqQ4XHj2C0N
Tm/2yEnZtvMaVq4rtnQU68/7JuMauh2WLmo7WJSJR1b/JaCTcFOD2oR0FMNnngRo
Ot+OQFodSk7PQ5E751bWAHDLUu57fa4657wx+UX2wmDPE1kCK4DMNEffud6QZW0C
zyyRpqbn3oUYSXxmTqM6bam17jQuug0DuDPfR+uxa40l2ZvOgdFFRjKWcIfeAg5J
Q4W2bHO7ZOphQazJ1FTfhy/HIrImzJ9ZVGif/L4qL8RVHHVAYBeFAlU5i38FAgMB
AAGjgfAwge0wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0O
BBYEFJxfAN+qAdcwKziIorhtSpzyEZGDMB8GA1UdIwQYMBaAFL9ft9HO3R+G9FtV
rNzXEMIOqYjnME8GCCsGAQUFBwEBBEMwQTAcBggrBgEFBQcwAYYQaHR0cDovL28u
c3MyLnVzLzAhBggrBgEFBQcwAoYVaHR0cDovL3guc3MyLnVzL3guY2VyMCYGA1Ud
HwQfMB0wG6AZoBeGFWh0dHA6Ly9zLnNzMi51cy9yLmNybDARBgNVHSAECjAIMAYG
BFUdIAAwDQYJKoZIhvcNAQELBQADggEBACMd44pXyn3pF3lM8R5V/cxTbj5HD9/G
VfKyBDbtgB9TxF00KGu+x1X8Z+rLP3+QsjPNG1gQggL4+C/1E2DUBc7xgQjB3ad1
l08YuW3e95ORCLp+QCztweq7dp4zBncdDQh/U90bZKuCJ/Fp1U1ervShw3WnWEQt
8jxwmKy6abaVd38PMV4s/KCHOkdp8Hlf9BRUpJVeEXgSYCfOn8J3/yNTd126/+pZ
59vPr5KW7ySaNRB6nJHGDn2Z9j8Z3/VyVOEVqQdZe4O/Ui5GjLIAZHYcSNPYeehu
VsyuLAOQ1xk4meTKCRlb/weWsKh/NEnfVqn3sF/tM+2MR7cwA130A4w=
-----END CERTIFICATE-----

authors: APAC-DevOps jonbesga rlagutinhub stevesloka stpabhi

repo: heptiolabs/gangway


text:
Raise exception on missing augeasproviders_core

People who manage their code with r10k have to resolve dependencies by
hand (or using a generator), as such we now helpfully raise an exception
when miaugeasproviders_core is missing.

Coverage increased (+0.04%) to 96.364% when pulling a5531ce6c901402dda10e57b765927a5f084c0ba on igalic:core_dep into b48597b56a48aa4cbae2f3866d32a67d6950c79b on hercules-team:master.

Coverage increased (+0.04%) to 96.364% when pulling a5531ce6c901402dda10e57b765927a5f084c0ba on igalic:core_dep into b48597b56a48aa4cbae2f3866d32a67d6950c79b on hercules-team:master.

authors: coveralls igalic


text:
MavenSupport: Add cache for remote artifacts

Store remote artifacts in a disk cache backed by DiskLruCache [1]. This
brings a big performance boost for Gradle, Maven and SBT dependency
resolution.
Currently the max cache size is hardcoded to 1GB, this will be made
configurable in a later commit.
[1] https://github.com/JakeWharton/DiskLruCache

This change is

Could you elaborate in the commit message why this makes sense? Naively thinking I would have assumed Maven artifacts get already cached by Maven itself in the standard local Maven directory. And even if they would not get cached implicitly, I would have assumed "turning on" the feature to cache in Maven-Local is less work than implementing an own cache with DiskLruCache.

authors: mnonnenmacher sschuberth

repo: heremaps/oss-review-toolkit


text:
Introduce Landlock isolation support

Leaving this here for now, the most important design problem with this is how Landlock does not allow whitelisting files if they are not created. (So, we'd have to force the user to use a directory for that instead.)
We also need to avoid "parsing" the same --file-mapping inputs twice, as well as not use OnceLock for enforcing the whitelist when the kernel is actually being loaded. UhyveVm::new is called in a new thread because Landlock enforces the restrictions for the entire process and its children. We're not testing if the sandbox is applied correctly yet.
See: https://docs.kernel.org/userspace-api/landlock.html
Fixes https://github.com/hermit-os/uhyve/issues/766

We need to move the split_guest_and_host functionality that is used during the initialization of UhyveFileMap::new away from that function for two reasons:

We need to be able to "hard fail" if a file does not exist and/or its parent directory is not whitelisted and we use Landlock instead of running absolute. See https://github.com/hermit-os/uhyve/pull/819.
We are effectively parsing the --file-mapping argument twice.

uhyvefilemap_test works. The problem is that you can't run UhyveVm::run multiple times, as the Landlock restrictions have already been applied process-wide once. Additionally, the temporary directory gets dropped after the first instance of UhyveVm::run, so trying to re-enforce Landlock causes an error as the temporary directory has been dropped.
My approach to the problem of "not being able to whitelist files that don't exist yet" is just whitelisting the parent directory and letting UhyveFileMap contain file operations to that one specific file only (in the whitelisted directory). We do that by iterating over the file's parents and establishing whether they exist, once - but this could be made configurable, and it should be fine if we disclose to the user that whitelisting directories is safer.
However, whitelisting a directory is not always practical, because we can't map the entirety of /root to anything yet, as the /root component gets popped by Uhyve before a hypercall is executed (see fs-test.rs and create_file.rs for a workaround), see: https://github.com/hermit-os/kernel/blob/12d4854554f8ec48fa66a8d282ebcf46b7bf9499/src/fs/mod.rs#L160

The change incorporates some changes from https://github.com/hermit-os/uhyve/pull/844.

repo: hermit-os/uhyve


text:
Allow storage objects to be JSON data other than objects

Description
The method for write objects in database are validating wrong the json format in the value parameter.
This value works OK: { "carName": "Demon", "selected": 1 }
This value NOT works: [{ "carName": "Demon", "selected": 1 }]
Both formats are valid. The “[]” in json is for represent an array, and it’s valid.
Steps to Reproduce
Write an object that contains a value with a json array.
Expected Result
It should be valid. In fact, i tested insert manually a json with array in storage table, and i can. So, it sounds like it's a wrong validation in the method.
Actual Result
The error msg is: Object value must be JSON.
Context
[ x ] Cocos2d-x c++ 3.17
Your Environment

Nakama: Server 2.4.0 and C++ SDK (in development)
Cockroach: Build Tag 2.1.3
Operating System and version: macOS Mojave 10.14.3

The server currently requires all storage values to be JSON objects, meaning top-level {}. This constraint may be loosened later but for now this is intended behaviour.
I've pushed an update to clear up the error message in https://github.com/heroiclabs/nakama/commit/e588901dfc7092095731e8452c469e7139b2cfea and will leave this open for discussion on allowing other top-level JSON types.

You can easily get around this restriction by wrapping the array in a field, I recommend this issue be closed, ex:
{
    cars: [{ "carName": "Demon", "selected": 1 }]
}

Hey @bhgsbatista. Thanks for the feedback. So far we've left this open as an improvement in the future because there's actually no limiting reason that we couldn't allow storage object values to be JSON array literals or even primitives.
I think it was just a historic decision that we can improve on 😄

I'm not sure what the intended usage is, but given the collection and key name columns, I assumed each object was supposed to represent one value e.g. settings/game_volume_percentage = 60.
We can definitely wrap the value in an object but it would be cool to avoid the overhead of serializing { value: <value> }.

@bryanmylee It's usually best for storage object values to contain a bit more than a single field like that. Using your example, settings should be a complex object with multiple keys in the value:
{
  "game_volume_percentage": 60,
  "music_enabled": true,
  ...
}

Reducing the number of database operations is preferred to reducing serialization overhead, even accounting for reading all settings at once even if you only need to check some or updating the whole object value when changing one.

authors: bhgsbatista bryanmylee novabyte raz0r007 zyro

repo: heroiclabs/nakama


text:
Migrate mattes/migrate to new repo golang-migrate/migrate

The mattes/migrate repo is archived since 8th May and superseded by golang-migrate/migrate now. Support for this repo instead (or mid-term both side-by-side to not break current app deployments) would be nice to keep up with features and security patches.
I might give the PR a try, but seeing how the repo patch is regexp in different tools (sed, grep, jq, tq) will likely make supporting both more complex that the benefit it offers.

Looking a bit closer, I actually believe this feature never worked, as the release binary filename (at least nowadays is migrate.linux-amd64.tar.gz not migrate-linux-amd64.tar.gz, which should have caused any in-the-wild users to raise issues.
So maybe a breaking change (and only supporting the new repo) is tolerable here.

Looking a bit further into the code, the additional-tools only supports migrate currently, which is not obvious from the README and support article. Maybe simplifying that feature and making it more flexible by letting its value be a script (as file or command[s]) in the repo to be run, is easier.
For example (and for compatibility reasons likely with a different key script|additional-script:
[metadata.heroku]
  additional-tools = ["./scripts/download_migrate.sh"]

or
[metadata.heroku]
  additional-tools = [
    [
      "curl -s -f -O migrate.tar.gz -L https://github.com/golang-migrate/migrate/releases/download/v3.4.0/migrate.linux-amd64.tar.gz",
      "tar xvz migrate.tar.gz",
    ]
  ]

Anyway, whole different can of worms.

repo: heroku/heroku-buildpack-go


text:
Add IntegrationTest::app_dir_preprocessor

This allows users to have the app directory (test fixture) to be modified in a safe way, just before the
integration test runs.
Usage Example
This is a cutlass test ported to libcnb-test for heroku/maven. Original cutlass test can be found here: https://github.com/heroku/buildpacks-jvm/blob/e91747a4310d566a2ecf3b88ce94ed86744c6346/test/specs/maven/misc_spec.rb#L3-L13
#[test]
#[cfg(target_family = "unix")]
pub fn maven_wrapper_executable_bit() {
    IntegrationTest::new(BUILDER_NAME, "../../test/fixtures/simple-http-service")
        .buildpacks(vec![
            BuildpackReference::Other(String::from("heroku/jvm")),
            BuildpackReference::Crate,
        ])
        .app_dir_preprocessor(|app_dir| {
            use std::os::unix::fs::PermissionsExt;
            fs::set_permissions(app_dir.join("mvnw"), Permissions::from_mode(0o444)).unwrap();
        })
        .run_test(|context| {
            assert_contains!(context.pack_stdout, "Successfully built image");
        });
}

Closes GUS-W-11177468

I assume your main concern is removing unnecessary IO during tests (the app_dir copy) for a slight speed-up?

Yeah

authors: Malax edmorley


text:
🛑 Software Center - Test 1 is down

In 624c0f1, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 851b330.

repo: herrphon/upptime


text:
🛑 Software Center - Test 1 is down

In b14a594, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 369bd66.


text:
🛑 Auth-Bridge - Test 1 is down

In 7ee66e9, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in edc8c61.


text:
🛑 Auth-Bridge - Test 1 is down

In e51e9c4, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in 9e0ec34.


text:
🛑 Software Center - Test 1 is down

In d005cbb, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in e697cf4.


text:
🛑 Software Center - Test 1 is down

In e611d9d, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 08a6e08.


text:
🛑 Software Center - Test 1 is down

In a6cf3c1, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 8dd44a6 after 40 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

In c2fc489, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in 6e32abd after 37 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

In 38a2cf8, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in cb75a0c after 18 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

In d1456cb, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in 7918d33 after 29 minutes.


text:
🛑 Software Center - Test 1 is down

In bc5b2c0, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in d8ecf97 after 10 minutes.


text:
🛑 Auth-Bridge - Test 1 is down

In 8a0d382, Auth-Bridge - Test 1 ($AUTH_BRIDGE_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Auth-Bridge - Test 1 is back up in ccf7ad4 after 59 minutes.


text:
🛑 Software Center - Test 1 is down

In b952167, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in bb03f7a after 10 minutes.


text:
🛑 Software Center - Test 1 is down

In cde3aab, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 9121e1d after 10 minutes.


text:
🛑 Software Center - Test 1 is down

In 3e6cb69, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 804576b after 30 minutes.


text:
🛑 Software Center - Test 1 is down

In b0c995c, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in bd0825e.


text:
🛑 Software Center - Test 1 is down

In 81c97b9, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 1c04d1b.


text:
🛑 Software Center - Test 1 is down

In 1275b6c, Software Center - Test 1 ($SOFTWARECENTER_TEST_1) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Software Center - Test 1 is back up in 638d555.


text:
Upgrade to MM v2.16 breaks this

[12.07.2021 11:04.20.344] [ERROR] WARNING! Could not load config file. Starting with default configuration. Error found: Error: Cannot find module 'rrule-alt'
Require stack:

/home/pi/MagicMirror/modules/MMM-CalendarWeek/vendor/ical.js/node-ical.js
/home/pi/MagicMirror/modules/MMM-CalendarWeek/vendor/ical.js/index.js
/home/pi/MagicMirror/modules/MMM-CalendarWeek/calendarfetcher.js
/home/pi/MagicMirror/modules/MMM-CalendarWeek/node_helper.js
/home/pi/MagicMirror/js/app.js
/home/pi/MagicMirror/js/electron.js
/home/pi/MagicMirror/node_modules/electron/dist/resources/default_app.asar/main.js

I tried fix in other issue post for v2.16 and it does not fix.

I had a similar " Could not load config file" error upgrading to MM 2.16.  The valid-url fix didn't work.  I rolled back to 2.15.

Issued the following and it is now working..
npm install rrule-alt
npm install valid-url

repo: heskja/MMM-CalendarWeek


text:
theme: hermes (updates)

Sorry for the multiple pulls so close together — I saw mine on the live site and decided it was too close to the original Apollo theme. Also, I updated the description to reflect that this theme has been updated to work out of the box (Apollo is essentially deprecated).
Check List
Please read and check followings before submitting a PR.

[x] I want to publish my theme on Hexo official website.

[x] I have read the theme publishing doc.
[x] name is unique.
[x] link URL is correct.
[x] preview URL is correct.
[x] preview URL web site is rendered correctly.
[x] Add a screenshot to source/themes/screenshots.
[x] Screenshot filename is same as value of name.
[x] Screenshot size is 800 * 500.
[x] Screenshot file format is png.

[ ] I want to publish my plugin on Hexo official website.

[ ] I have read the plugin publishing doc.
[ ] name is unique.
[ ] link URL is correct.

[ ] Others (Update, fix, translation, etc...)

Force push because I accidentally included a package bump. Not sure when now this says there are conflicts to resolve, there shouldn't be 🤷♂

@SukkaW does this look okay?

This PR is still has conflicts that need to be resolved...

Fixed!

Thanks for your contribution. However, this commit is not clean. I have created a new PR #1222 please have a look.

authors: NoahDragon SukkaW claymcleod

repo: hexojs/site


text:
add hexo-admin-ehc in plugin.xml

hi, this is a new hexo plugin based on hexo-admin, adding several improvement such as image uploader UI and a new gallery popover for image insert, just simplely two click to complete.

Please resolve the conflicts, thanks.


text:
Add testing

Found #8 while adding this

Oops good catch @joshmanders, fixed

Does this still look okay with the latest merge?

I rebase on master its all good still.
@heybourn do you have a preference between keeping the tests in src/, or moving them to a top level /tests folder?
Right now I've keeping them together with the files in src.

I'm not too worried. What is best practice usually?

I am not either we can leave it like this for now and move it later if we need to for whatever reason.
Re best practices I've seen it both ways, @joshmanders any input on this?

Depends on your preferences really. Large projects can benefit from keeping the tests with the source, so you're not pile driving through trees of directories mirroring, but for this project it might be better to have them in a top level tests/ folder.
Also I'd probably swap to using Jest over Mocha as it's more user friendly and has basically become the goto test harness for JavaScript projects.

Switching to Jest can be pretty easy, just drop mocha and chai from devDependencies, add jest and remove all import {expect} from 'chai' calls, as expect is already apart of Jest's global functions (like describe and it)

@praveenperera let's roll with what Josh has said here. I like the idea of a /tests folder for now.

Done we now have the new scripts:
npm run test
npm run test:watch
npm run test:coverage

LGTM 👍

File '/Users/ryan/Desktop/github/headwind/tests/utils.spec.ts' is not under 'rootDir' '/Users/ryan/Desktop/github/headwind/src'. 'rootDir' is expected to contain all source files.

authors: heybourn joshmanders praveenperera

repo: heybourn/headwind


text:
Missing prefetch options?

According to the documentation in libxsmm_be.md, there should be options to prefetch into L1:
10. "AL1": prefetch A' into L1 via accesses to A
11. "BL1": prefetch B' into L1 via accesses to B
12. "CL1": prefetch C' into L1 via accesses to C
13. "AL1_BL1": prefetch A' and B' into L1
14. "BL1_CL1": prefetch B' and C' into L1
15. "AL1_CL1": prefetch A' and C' into L1
16. "AL1_BL1_CL1": prefetch A', B', and C' into L1

However when trying to use them with the generator I get
wrong usage -> exit!

Usage (sparse*dense=dense, dense*sparse=dense):
    sparse, sparse_csr, sparse_csr_reg
    filename to append
    routine name
    M
    N
    K
    LDA (if < 1 --> A sparse)
    LDB (if < 1 --> B sparse)
    LDC
    alpha: 1
    beta: 0 or 1
    0: unaligned A, otherwise aligned (ignored for sparse)
    0: unaligned C, otherwise aligned (ignored for sparse)
    ARCH: noarch, wsm, snb, hsw, knl, knm, skx, clx, cpx
    PREFETCH: nopf (none), pfsigonly, other dense options fall-back to pfsigonly
    PRECISION: SP, DP
    matrix input (CSC mtx file)

Usage (dense*dense=dense):
    dense, dense_asm
    filename to append
    routine name
    M
    N
    K
    LDA
    LDB
    LDC
    alpha: -1 or 1
    beta: 0 or 1
    0: unaligned A, otherwise aligned
    0: unaligned C, otherwise aligned
    ARCH: noarch, wsm, snb, hsw, knl, knm, skx, clx, cpx
    PREFETCH: nopf (none), pfsigonly, BL2viaC, AL2, curAL2,
              AL2_BL2viaC, curAL2_BL2viaC,
    PRECISION: I16, SP, DP

And the options are not in the list of available ones.
I'm using the latest version: master-1.16.1-1252
The documentation seems to be quite old so maybe the options were removed since then?

Thank you for your report!
There was a cleanup wrt prefetch strategies, and the documentation might be outdated (libxsmm_be.md). I am sorry for this, I will take a look and match with the current implementation.
You probably read that the stand-alone generator is discouraged from use as it will not receive updates regarding future ISA extensions. I will let @alheinecke to jump in if your case is on a particular application like SeisSol. Anyhow, it would good to find a path using our API rather than the stand-alone generator. Let us know how we can help.

OK, then I assume there is no way to get prefetching to L1 or any prefetching of C' with the generator given the options supported by the generator?
I'm working on the ExaHyPE application (similar to SeisSol) and we are using the generator with our code generation to include the gemm in our single core compute kernels. We are using Loop-over-GEMM to perform tensor contraction operations, which I described briefly in this paper https://arxiv.org/pdf/2003.12787.pdf (section III-B), so prefetching the next tensor slice (=matrix) within the gemm was something I wanted to try out as we seem to be cache bound.
Here is an example of how we do the LoG with the gemm
for (int yz = 0; yz < 36; yz++) {
  gemm_16_6_6_gradQ_x_sck(lQi+yz*96, dudxT_by_dx, gradQ+yz*96);
}

Usually in our MM, B is a fixed coefficient matrix and we have sequential slices of our input and output tensor as A and C to process (with other data layouts we might need to have A as the coef matrix and B the input slice).
I could always try to see if prefetching myself the next slices before calling the gemm using intrinsics is enough even if it most certainly will be less efficient than having the prefetching optimized inside the gemm code.
If we were to remove the call to the generator, is there a way to avoid JIT and get the production and compilation of the gemms at compile time? In our case every relevant MM parameter to set up a gemm is known and hard-coded before compilation.

This sounds a lot like our BRGEMM kernel (Batch-Reduce GEMM kernel), which is still a series of GEMMs (Beta=1). However, in contrast to prefetched singular GEMMs, it is meant for cases that are not exactly DRAM/memory bound. Looking at your pseudo-code, it appears you can just use our API for either case. You really want to avoid the stand-alone generator for above reasons (deprecated). If you argue about dispatch overhead, your code looks like it can dispatch a single kernel prior to the loop, and easily amortize the dispatch by running that same (and already dispatched) kernel repeatedly inside of the loop. With BRGEMM, you can perform perhaps some (if not all trips) as part of the kernel itself and solve your cache bottleneck.
For singular GEMMs, we have two dispatch flavors, a weak/un-typed variant (libxsmm_xmmdispatch) and strong-typed variants (e.g., for double-precision). There are tons of examples showing either variant including our Hello LIBXSMM. For libxsmm_xmmdispatch, one can find the functions to build a descriptor here, and related flags are here.
The BRGEMM kernel however has some more prerequisites like input data format, e.g., whether indexes, pointers, strides, etc. There are strong-typed variants (see https://github.com/hfp/libxsmm/blob/master/include/libxsmm.h#L177 and many following lines), but I recommend to go for libxsmm_xmmdispatch (same as for singular GEMMs). It is just a matter of building a descriptor requesting a BRGEMM rather than a GEMM-kernel (see here to select from available flags). Perhaps the "kernel" sample (part of our xgemm sample code) can help to estimate performance for your case (I am sorry for the command line interface ;-).

If we were to remove the call to the generator, is there a way to avoid JIT and get the production and compilation of the gemms at compile time? In our case every relevant MM parameter to set up a gemm is known and hard-coded before compilation.

You could go lazy and just take the dispatch as you can expect it to be amortized (same kernel dispatched once per loop). Dispatch (as opposed to first time JIT code generation) takes in the order of tens of Nanoseconds (e.g., 50 ns) if you dispatch repeatedly from a limited set of kernels (we have a per-thread cache; see here for details). If you need multiple different kernels inside of a loop, you can also dispatch multiple kernels at once. However, your application just permits to have no dispatch overhead by simply dispatching the kernels you need during startup and then keep the function pointers around. Dispatch is only necessary if this upfront knowledge is not available. For example:
int main(int argc, char* argv[])
{
  libxsmm_descriptor_blob blob;
  libxsmm_gemm_descriptor *desc = libxsmm_gemm_descriptor*(&blob, ...);
  /* function pointer kernel_16_6_6 remains valid for the lifetime of your application */
  libxsmm_xmmfunction kernel_16_6_6 = libxsmm_xmmdispatch(desc);
  ...
  /* you can call "kernel_16_6_6" whenever/wherever you want without JIT/disptach overhead */
}

I'll look into it then. I have been using the generator for 5 years and since the ExaHyPE project is almost over, it is probably something that will be used for ExaHyPE2. But I can try to see if we can do the switch easily in a proof of concept use case.

You could go lazy and just take the dispatch as you can expect it to be amortized (same kernel dispatched once per loop). Dispatch (as opposed to first time JIT code generation) takes in the order of tens of Nanoseconds (e.g., 50 ns) if you dispatch repeatedly from a limited set of kernels (we have a per-thread cache; see here for details).

Just to be sure I understand you correctly. Once I have the descriptor, when I call the dispatch the first time JIT occurs but then the gemm compiled function stays cached and can be reused at no more cost than a function call the next time the dispatch is called inside the loop?
If yes would it stay cached if I call again at a later time my function using it, or not? Or do I need to set up a function pointer that will stay alive (for example in an object storing the ~10 gemm I need) as you propose?
My fear is that the matrices involved are already sometime very small (8x16 is typical on skx) so a JIT overhead could be significant. Furthermore the generator was really convenient as we already use code generation on our side to tailor the application toward a given architecture and setup so integrating the generated gemms is easy. We would probably lose a bit from going away from the generator (as we even use #pragma forceinline to even remove the function call overhead) but if we gain access to more complex and advanced configurations, in particular L1 prefetching, it could pay off.

Once I have the descriptor, when I call the dispatch for the first time JIT occurs but then the gemm compiled function stays cached and can be reused at no more cost than a function call the next time the dispatch is called inside the loop. Is it right?

Jitted code is buffered for the lifetime of the application ("code registry"). We distinct "code generation" (initial dispatch; 10s of Mikroseconds) and "dispatch" (further we have "hot" and "cold"). If you keep the function pointer on your record, there is no need to ever dispatch it again. If you still do so (e.g., for convenience), you will not regenerate the code but receive already generated code from that code registry. Jitted code is like any other function pointer like one that refers to code generated by your regular compiler.
The only difference might be that an indirect call (via function pointer) cannot be inlined, whereas a function pointer that came from a statically compiled function might be inlined (if the compiler was able to track the value of the pointer, i.e., know which code it refers to). An indirect function call is also nothing to worry for these kernels since we talk about one additional instruction when compared to inlined code. In fact, it is likely your compiler does not inline, e.g., gemm_16_6_6_gradQ_x_sck.
Think of dispatch like a service that allows your to determine a function pointer that matches your call arguments. In your application you do not need this service, you can prepare a known set of function pointers upfront that match a fixed/known set of parameters/call arguments.

If yes would it stay cached if later I call my function using it again, or not? Or do I need to set up a function pointer that will stay alive (for example in an object storing the ~10 gemms I need) as you propose?

The cache size (thread-local) can be configured at build-time (default size is 16 entries). However, the cache only gives you a lower dispatch time (10s of Nanoseconds) whereas storing/keeping them on your own is zero dispatch time (since you know which pointer you need to call).

I have updated our documentation. If any help is needed (now or later) for transitioning ExaHyPE away from the stand-alone generator, let me know. Again, thank you for reporting this issue!

authors: gallardjm hfp

repo: hfp/libxsmm


text:
chore(package): update tslint to version 5.7.0

Closes #232

Coverage remained the same at 7.863% when pulling 164e7ec0906a1e5309f1f08f01ce36812b144d08 on greenkeeper/tslint-5.7.0 into 2669f1bcea903ee8ca3d6d7812259df8b3e89570 on master.

authors: coveralls hfreire

repo: hfreire/get-me-a-date


text:
App image throws error but Flatpak works

Subject of the issue
Ywallet appimage throws below error
tmp/.mount_YwalleyAN6K0/ywallet: symbol lookup error: /tmp/.mount_YwalleyAN6K0/usr/lib/x86_64-linux-gnu/libgdk-3.so.0: undefined symbol: wl_proxy_marshal_flags
The corresponding version of Ywallet in flatpak works.
Environment

version of YWallet: 1.4.3+473
Debian 11

Duplicate of #84


text:
🛑 Hacker News is down

In c84ba8a, Hacker News (https://news.ycombinator.com) was down:

HTTP code: 502
Response time: 318 ms

Resolved: Hacker News is back up in 89d6a9e.

repo: hialvaro/upptime-test