Made docker file a whole lot smaller! (67% to be exact)

Short Description:
Rebased the docker to use alpine python build since it's a lot lighter and easier to download and handle on low connections speed

please wait for merge trying to optimize it even more

@TheSavior save to merge now :)
if someone else has an idea on how to make it even smaller let me know.

Please keep the following ENTRYPOINT code
ENTRYPOINT ["python", "pokecli.py"]

In order to execute docker image and pass parameters, such as ptc, username, password

@nivong isn't this a bit odd? why would one run setup.sh -i during docker build. why would i save my username and password in the docker image?

@mjmadsen: this creates some security concerns for me if the username and password are in the docker image.

Sorry it's not the file that is smaller it's the installation.  Now it's 800 something MB. This puts it down to 299 MB by using alpine Linux. But I'm new to docker so if there is a better way of streamlining the whole thing please do!
I used setup.sh because installation instructions might be updated in the feature to not have to edit everything I used the setup.sh
And yes you won't be promoted ;)  tested that out ofc

Good point about the entry point will change that asap when I'm back in the office (sorry about the stupid close fat fingers)

@nivong kudos for using alpine that part i totally agree and support
my 2 cents were regarding the readability and transparency of what the Dockerfile does

Thanks will clean it up a bit. Could you perhaps contribute too? You can pr to the dev branch in my fork to update it here. Like I said I'm totally new at docker and not Linux. So if you have a better idea I'm all ears and eyes!

@th3w4y updated, is this more like it?

@nivong
looks good
but check below version for the ADD directly from github
that way if user has any file modified they don't get pulled in by docker build.
FROM python:2.7.12-alpine

RUN apk add --update --no-cache alpine-sdk bash wget git

ADD https://github.com/PokemonGoF/PokemonGo-Bot/archive/dev.tar.gz .
RUN tar -zxvf dev.tar.gz && mv PokemonGo-Bot-dev /usr/src/app && rm dev.tar.gz

WORKDIR /usr/src/app
VOLUME ["/usr/src/app/configs", "/usr/src/app/web"]

ARG timezone=Etc/UTC
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

#setup the bot
RUN cd /tmp && wget http://pgoapi.com/pgoencrypt.tar.gz \
    && tar zxvf pgoencrypt.tar.gz \
    && cd pgoencrypt/src \
    && make \
    && cp libencrypt.so /usr/src/app/encrypt.so \
    && cd /tmp \
    && rm -rf /tmp/pgoencrypt*

ENV LD_LIBRARY_PATH /usr/src/app

RUN ln -s /usr/include/locale.h /usr/include/xlocale.h
RUN pip install --no-cache-dir -r requirements.txt

#remove unused stuff
RUN apk del alpine-sdk\
  && apk cache clean\
  && rm -rf /var/cache/apk/*

ENTRYPOINT ["python", "pokecli.py"]

no idea what it does but you have more knowledge than me ;) added it!

@nivong check https://github.com/nivong/PokemonGo-Bot/pull/4

@nivong thanks

@nivong: before you take out wget you would have to modify the Dockerfile like this:
-RUN cd /tmp && wget http://pgoapi.com/pgoencrypt.tar.gz \
-      && tar zxvf pgoencrypt.tar.gz \
+ADD http://pgoapi.com/pgoencrypt.tar.gz /tmp/
+RUN cd /tmp && tar zxvf pgoencrypt.tar.gz \

as for git i don't  know if is used

can you do a PR to my fork :) ? but swampt today

@nivong https://github.com/nivong/PokemonGo-Bot/pull/6

@nivong please pull in also https://github.com/nivong/PokemonGo-Bot/pull/7 otherwise the suggestion i have with pulling the archive from github.com and the fact that i hardcoded dev will not be compatible with the master branch

check!

@th3w4y this comes up on testing the docker build:
Step 21 : RUN apk del alpine-sdk   && rm -rf /var/cache/apk/*
 ---> Running in 2ba527e2474e
WARNING: Ignoring APKINDEX.167438ca.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.a2e6dac0.tar.gz: No such file or directory
Removing intermediate container 2ba527e2474e
The command '/bin/sh -c apk del alpine-sdk   && rm -rf /var/cache/apk/*' returned a non-zero code: 1

Why is this a problem out of the blue? Worked before....

@nivong checking now...
docker build https://raw.githubusercontent.com/nivong/PokemonGo-Bot/691037348b7d40649f8c507e73a12334854b5526/Dockerfile
... still building

@nivong
I found the cullprit that step si ruined twice....

#remove unused stuff
RUN apk del alpine-sdk\
  && rm -rf /var/cache/apk/*

ENTRYPOINT ["python", "pokecli.py"]

#remove unused stuff
RUN apk del alpine-sdk \
  && rm -rf /var/cache/apk/*

ENTRYPOINT ["python", "pokecli.py"]

lol how did that happen, changed it thanks for checking, if you have more please do a PR i am out of the office again

@nivong sorry was my bad in commit<PHONE_NUMBER>11bd08038b337487b09d68e73787ce   i copy paste from my file over the text in the github.com editor and probably some lines remain unselected when pasting over.

@nivong now all looks good  👍
14:06 $ docker build https://raw.githubusercontent.com/nivong/PokemonGo-Bot/8832b16f610bbc7ea7cbce10b8c682450a6d05da/Dockerfile
Downloading build context from remote url: https://raw.githubusercontent.com/nivong/PokemonGo-Bot/8832b16f610bbc7ea7cbce10b8c682450a6d05da/Dockerfile  1.56 kB
Sending build context to Docker daemon 3.584 kB
Step 1 : FROM python:2.7.12-alpine
 ---> 67fa4e31547b
Step 2 : RUN apk add --update --no-cache alpine-idk git
 ---> Using cache
 ---> a4ae9dd908be
Step 3 : ARG BUILD_BRANCH
 ---> Using cache
 ---> 321d0cbbdaf6
Step 4 : ENV BUILD_BRANCH ${BUILD_BRANCH:-master}
 ---> Using cache
 ---> 2dcad1163c8d
Step 5 : ARG BUILD_REPO
 ---> Using cache
 ---> b4eaf959943c
Step 6 : ENV BUILD_REPO ${BUILD_REPO:-PokemonGoF/PokemonGo-Bot}
 ---> Using cache
 ---> 12cc3e912e5d
Step 7 : LABEL build_repo $BUILD_REPO build_branch $BUILD_BRANCH
 ---> Using cache
 ---> 06c9d4154b8c
Step 8 : ADD https://github.com/$BUILD_REPO/archive/$BUILD_BRANCH.tar.gz .
Downloading [==================================================>] 3.521 MB/3.521 MB
 ---> Using cache
 ---> ec957c9739f9
Step 9 : RUN tar -zxvf $BUILD_BRANCH.tar.gz && mv PokemonGo-Bot-* /usr/src/app && rm $BUILD_BRANCH.tar.gz
 ---> Using cache
 ---> 047661f5c49e
Step 10 : WORKDIR /usr/src/app
 ---> Using cache
 ---> c39fa7fe8bbc
Step 11 : VOLUME /usr/src/app/configs /usr/src/app/web
 ---> Using cache
 ---> 47815483d5f0
Step 12 : ARG timezone=Etc/UTC
 ---> Using cache
 ---> 9ca574da35f9
Step 13 : RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
 ---> Using cache
 ---> 2bc5d76191de
Step 14 : ADD http://pgoapi.com/pgoencrypt.tar.gz /tmp/
Downloading [==================================================>] 243.6 kB/243.6 kB
 ---> Using cache
 ---> dc84fb88af8b
Step 15 : RUN cd /tmp && tar zxvf pgoencrypt.tar.gz     && cd pgoencrypt/src     && make     && cp libencrypt.so /usr/src/app/encrypt.so     && cd /tmp     && rm -rf /tmp/pgoencrypt*
 ---> Using cache
 ---> 861c0b5a4784
Step 16 : ENV LD_LIBRARY_PATH /usr/src/app
 ---> Using cache
 ---> eb78d51f0398
Step 17 : RUN ln -s /usr/include/locale.h /usr/include/xlocale.h
 ---> Using cache
 ---> fa24a7864b5c
Step 18 : RUN pip install --no-cache-dir -r requirements.txt
 ---> Using cache
 ---> 0e858ca5141c
Step 19 : RUN apk del alpine-sdk  && rm -rf /var/cache/apk/*
 ---> Using cache
 ---> 7f5393c52c4e
Step 20 : ENTRYPOINT python pokecli.py
 ---> Using cache
 ---> d483306518cb
Successfully built d483306518cb
(anaconda3) (root) ✔ ~
14:06 $ echo $?
0
(anaconda3) (root) ✔ ~
14:06 $

Thanks for the merge @solderzzc and thanks @th3w4y for the help :)


[rtl] Ibex services interrupts when single stepping

Ibex hard-codes dcsr.stepie to 0, meaning when single-stepping is enabled all interrupts should be masked. From trials with debugging on https://github.com/GregAC/ibex_super_system this is not the observed behaviour, a single step can enter an instruction handler.
In addition to fixing this we should look at our existing DV to determine if this bug could have been caught by it (single step tests are failing in the nightly regression so potentially have already found the bug, we just haven't had the time to look at the failures yet)

estimate 4

@hcallahan-lowrisc have come across any behaviour around single stepping and interrupts in your debug DV work?


Updating row data re-renders the whole table instead of just the row data

Updating row data re-renders the whole table instead of just the row data

Expected Behavior
The row data should update when it receives the new data

Current Behavior
The whole component renders again, even losing state data such as "Rows per page(It goes back to the default one)".
Also, i noticed the tag at the end of each table component changes with each update (MUIDataTableBodyCell-root-2825  (Notice the 2825, it goes up by 100 or 200 on each update))

Steps to Reproduce (for bugs)

https://codesandbox.io/s/dreamy-forest-yjupp?file=/src/App.js

Inspect one of the rows of the table with your browser.
Change the rows per page option.
Press the update button below the table.
Watch the table row id change to a higher one and the rows per page option reset to default

(edit)
I found out the id's thing was because i declared the MUI theme inside of the component, but the rows per page issue still remains
Your Environment

Tech
Version

Material-UI
4.11.3

MUI-datatables
3.7.4

React
17.0.1

browser
Chrome

Material-UI/icons
4.11.2

  const options = {
    filterType: "multiselect",
    resizableColumns: false,
    pagination: true,
    responsive: "standard",
    rowsPerPage: 10,
    rowsPerPageOptions: [5, 10, 20, 50, 100],
    selectableRowsOnClick: false,
    selectToolbarPlacement: "none",
    selectableRowsHideCheckboxes: true,
    tableBodyHeight: "300px",
    viewColumns: "true",
    draggableColumns: { enabled: true, transitionTime: 300 },
    onRowClick: (e) => {
      // ChngCoord(state, setState);
    }
  };

This is normal operation due to the component structure.
If you change the parent's state, it is updated & re-render.
Remove rowsPerPage

Please check and close the issue.

That was the problem, thanks!!!


feat: Implement verify method

Related Issues
fixes #20 #33
Thanks to @tkfinitefield

Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).

[ ] I have updated the CHANGELOG.md of the relevant packages.
Changelog files must be edited under the form:
## Unreleased fix/major/minor

- Description of your change. (thanks to @yourGithubId)

[x] If this contains new features or behavior changes,
I have updated the documentation to match those changes.

As mentioned in the original PR, we'd want tests :)

@rrousselGit
I'm having difficulty designing test scenarios when trying to write test code.
I think testing the process of encoding and decoding a dummy JWT token might be a good approach, but I'm curious to hear your thoughts.
If you have the time, I'd be interested in collaborating on writing the tests.

are there any updates?

I couldn't modify this PR so I created a new one: https://github.com/invertase/dart_firebase_admin/pull/54.
The changes are mostly copied over except I tried to reuse the existing verifyJwtSignature function.
The unit tests verify the 'kid' handling that is added to the verify function.

Closing since there's a new PR


Does not support ISO 8601 comma separator

I was debugging a problem with parsing the following date string, which moment was calling invalid:
2015-08-09T12:10:51,555

According to the WP article, this is valid and the preferred millisecond separator in the standard:

A decimal mark, either a comma or a dot (without any preference as stated in resolution 10 of the 22nd General Conference CGPM in 2003,[14] but with a preference for a comma according to ISO 8601:2004)[15] is used as a separator between the time element and its fraction.

Should moment support this?

Yes, it's true that ISO-8601 spec states that a comma is prefered, but in practice - that bit of advice is almost never implemented.  Just about every ISO-8601 parser I've worked with only accepts a period.  Though some will use a period or a decimal depending on what culture settings are in place.  Given that ISO-8601 strings are used as a common interchange format, and you don't always know what's interpreting it, I recommend only using periods (despite the spec).
Though, since it's in the spec, we should probably support it anyway.
Edited #2450 to include this.  Closing this in favor of #2450.


Getting connection refused or tor site down.

Problem/Motivation
I did set it up just like the manual says,
added these ports
443
<IP_ADDRESS>:8123:8080
Socks and stealth disabled.
getting this error
Aug 06 17:16:27.000 [info] connection_handle_write_impl(): in-progress connect failed. Removing. (Connection refused)
and this one
Aug 06 18:03:03.000 [debug] circuit_remove_handled_ports(): Port 443 is already being handled; removing.
Is this because my homeassistant is using https ?
more log debug info:
Aug 06 17:16:24.000 [info] internal circ (length 4, last hop torstejaude): $6287129CB9EC475EXXXXXX283FE4E45D632A4A4B(open) $EE2A621042994B29452C12FXXXXXXE957758C(open) $EC16F2B1D13F658XXXXXX7856995828D18F32CC0(open) $2C67000893E1846D43FC00XXXXXCD81FF26C(waiting for keys)
Aug 06 17:16:24.000 [info] circuit_mark_for_close_(): Circuit<PHONE_NUMBER> (id: 75) marked for close at src/core/or/circuituse.c:831 (orig reason: -3, new reason: 0)
Aug 06 17:16:24.000 [info] circuit_free_(): Circuit 0 (id: 75) has been freed.
Aug 06 17:16:27.000 [info] connection_handle_write_impl(): in-progress connect failed. Removing. (Connection refused)
Aug 06 17:16:27.000 [info] connection_handle_write_impl(): in-progress connect failed. Removing. (Connection refused)
Aug 06 17:16:31.000 [info] connection_handle_write_impl(): in-progress connect failed. Removing. (Connection refused)
Aug 06 17:16:32.000 [info] connection_handle_write_impl(): in-progress connect failed. Removing. (Connection refused)
Aug 06 17:16:43.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 1 to [scrubbed] ([scrubbed]) after 3963 ms. Delta 2ms
Aug 06 17:16:43.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 2 to [scrubbed] ([scrubbed]) after 4386 ms. Delta 2ms
Aug 06 17:16:49.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 1 to [scrubbed] ([scrubbed]) after 5348 ms. Delta 3ms
Aug 06 17:16:50.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 2 to [scrubbed] ([scrubbed]) after 6722 ms. Delta 6ms
Aug 06 17:16:56.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 1 to [scrubbed] ([scrubbed]) after 4963 ms. Delta 2ms
Aug 06 17:17:01.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 1 to [scrubbed] ([scrubbed]) after 4569 ms. Delta 4ms
Aug 06 17:17:06.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 2 to [scrubbed] ([scrubbed]) after 6520 ms. Delta 2ms
Aug 06 17:17:07.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 1 to [scrubbed] ([scrubbed]) after 6786 ms. Delta 15ms
Aug 06 17:17:10.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 2 to [scrubbed] ([scrubbed]) after 3722 ms. Delta 2ms
Aug 06 17:17:12.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 1 to [scrubbed] ([scrubbed]) after 4620 ms. Delta 5ms
Aug 06 17:17:16.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 1 to [scrubbed] ([scrubbed]) after 4057 ms. Delta 2ms
Aug 06 17:17:30.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 2 to [scrubbed] ([scrubbed]) after 9003 ms. Delta 1ms
Aug 06 17:17:36.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 2 to [scrubbed] ([scrubbed]) after 6305 ms. Delta 3ms
Aug 06 17:17:42.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 1 to [scrubbed] ([scrubbed]) after 5089 ms. Delta 1ms
Aug 06 17:17:43.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 2 to [scrubbed] ([scrubbed]) after 7108 ms. Delta 4ms
Aug 06 17:17:46.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 1 to [scrubbed] ([scrubbed]) after 3684 ms. Delta 3ms
Aug 06 17:17:53.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 2 to [scrubbed] ([scrubbed]) after 9203 ms. Delta 2ms
Aug 06 17:17:57.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 2 to [scrubbed] ([scrubbed]) after 4036 ms. Delta 2ms
Aug 06 17:18:02.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 1 to [scrubbed] ([scrubbed]) after 8138 ms. Delta 2ms
Aug 06 17:18:02.000 [info] channelpadding_send_padding_cell_for_callback(): Sending netflow keepalive on 2 to [scrubbed] ([scrubbed]) after 5488 ms. Delta 3ms

an error on my side


GHC Panic: static flags have not been initialized

On Windows 7 with GHC 7.8.2 (the output below is from MSYS, but I've also had the same happen in Cygwin and PowerShell), I run into this error when trying to execute hermit:
$ hermit Last.hs
[starting HERMIT v<IP_ADDRESS> on Last.hs]
% ghc Last.hs -fforce-recomp -O2 -dcore-lint -fsimple-list-literals -fexpose-all-unfoldings -fplugin=HERMIT -fplugin-opt=HERMIT:*:
[1 of 1] Compiling Main             ( Last.hs, Last.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-<IP_ADDRESS> ... linking ... done.
Loading package deepseq-<IP_ADDRESS> ... linking ... done.
Loading package bytestring-<IP_ADDRESS> ... linking ... done.
Loading package containers-<IP_ADDRESS> ... linking ... done.
Loading package Win32-<IP_ADDRESS> ... linking ... done.
Loading package filepath-<IP_ADDRESS> ... linking ... done.
Loading package old-locale-<IP_ADDRESS> ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package directory-<IP_ADDRESS> ... linking ... done.
Loading package pretty-<IP_ADDRESS> ... linking ... done.
Loading package process-<IP_ADDRESS> ... linking ... done.
Loading package Cabal-<IP_ADDRESS> ... linking ... done.
Loading package binary-<IP_ADDRESS> ... linking ... done.
Loading package bin-package-db-<IP_ADDRESS> ... linking ... done.
Loading package hoopl-<IP_ADDRESS> ... linking ... done.
Loading package hpc-<IP_ADDRESS> ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package transformers-<IP_ADDRESS> ... linking ... done.
Loading package ghc-7.8.2 ... linking ... done.
Loading package ansi-terminal-<IP_ADDRESS> ... linking ... done.
Loading package data-default-class-0.0.1 ... linking ... done.
Loading package data-default-instances-base-0.0.1 ... linking ... done.
Loading package data-default-instances-containers-0.0.1 ... linking ... done.
Loading package dlist-<IP_ADDRESS> ... linking ... done.
Loading package data-default-instances-dlist-0.0.1 ... linking ... done.
Loading package data-default-instances-old-locale-0.0.1 ... linking ... done.
Loading package data-default-0.5.3 ... linking ... done.
Loading package haskeline-<IP_ADDRESS> ... linking ... ghc: warning: SetConsoleCursorPosition from kernel32 is linked instead of __imp_SetConsoleCursorPosition
ghc: warning: FillConsoleOutputCharacterA from kernel32 is linked instead of __imp_FillConsoleOutputCharacterA
ghc: warning: FillConsoleOutputAttribute from kernel32 is linked instead of __imp_FillConsoleOutputAttribute
done.
Loading package kure-2.16.2 ... linking ... done.
Loading package marked-pretty-0.1 ... linking ... done.
Loading package mtl-<IP_ADDRESS> ... linking ... done.
Loading package random-<IP_ADDRESS> ... linking ... done.
Loading package operational-<IP_ADDRESS> ... linking ... done.
Loading package stm-2.4.3 ... linking ... done.
Loading package exceptions-0.6.1 ... linking ... done.
Loading package temporary-<IP_ADDRESS> ... linking ... done.
Loading package hermit-<IP_ADDRESS> ... linking ... done.
===================== Welcome to HERMIT ======================
HERMIT is a toolkit for the interactive transformation of GHC
core language programs. Documentation on HERMIT can be found
on the HERMIT web page at:
http://www.ittc.ku.edu/csdl/fpg/software/hermit.html

You have just loaded the interactive shell. To exit, type
"abort" or "resume" to abort or resume GHC compilation.

Type "help" for instructions on how to list or search the
available HERMIT commands.

To get started, you could try the following:
  - type "binding-of 'foo", where "foo" is a function
    defined in the module;
  - type "set-pp-type Show" to display full type information;
  - type "info" for more information about the current node;
  - to descend into a child node, type the name of the child
    ("info" includes a list of children of the current node);
  - to ascend, use the "up" command;
  - type "log" to display an activity log.
==============================================================

WARNING: HERMIT invoked in a Unix-like shell such as Cygwin.
Cygwin does not handle Ctrl-C or tab completion well in some
Haskell executables. It is recommended that you use a native
Windows console (such as cmd.exe or PowerShell) instead.

ghc: panic! (the 'impossible' happened)
  (GHC version 7.8.2 for x86_64-unknown-mingw32):
        Static flags have not been initialised!
        Please call GHC.parseStaticFlags early enough.

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

After poking around HERMIT.Shell.Command for a while with Debug.Trace, it appears that the culprit is the showWindow function from HERMIT.Shell.Types. I'm not sure what exactly showWindow is doing that could be causing a GHC panic though.
Those linker warnings about Haskeline also seem strange, but I don't think Haskeline is the culprit, as I can run this example without any problems (other than the warnings).

Trac #10301 appears to have been resolved, so I think this is no longer an issue.


⚠ Bofrost.at has degraded performance

In 8330f5e, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1571 ms

Resolved: Bofrost.at performance has improved in 2d5f6a4 after 6 minutes.


feat(esl-popup): internal ESLPopup implementation updated to use ESLEventListeners; usage of cached properties reduced

Closes: #2009

:tada: This PR is included in version 4.14.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


support cloudfront page

I tried to apply this lib for my personal project on cloudfront page. but It doesn't work with this error:
$ npm run start

> start
> npm run dev:wrangler

> dev:wrangler
> wrangler pages dev ./public --watch ./build

Compiling worker to "/var/folders/3s/74fw0j915232w50ctbnxyg7c0000gn/T/functionsWorker.js"...
Compiled Worker successfully.
[pages:err] TypeError: Cannot read properties of undefined (reading 'FileSystemBackend')
    at build/index.js (/Users/test/project-name/app/i18n.server.ts:5:34)
    at __init (/var/folders/3s/74fw0j915232w50ctbnxyg7c0000gn/T/functionsWorker.js:16:56)
    at functions/[[path]].js (/Users/test/project-name/functions/[[path]].js:4:1)

Is it available to support remix project on cloudfront?

https://github.com/sergiodxa/remix-i18next#custom-backend
sorry i found this

I found about custom backend in README, so I tried to use FetchBackend but it also doesn't work with this error 🤔 :
$ npm run start

> start
> npm run dev:wrangler

> dev:wrangler
> wrangler pages dev ./public --watch ./build

Compiling worker to "/var/folders/3s/74fw0j915232w50ctbnxyg7c0000gn/T/functionsWorker.js"...
Compiled Worker successfully.
[pages:err] TypeError: import_remix_i18next2.FetchBackend is not a constructor
    at build/index.js (/Users/test/project-name/build/index.js:41:15)
    at __init (/var/folders/3s/74fw0j915232w50ctbnxyg7c0000gn/T/functionsWorker.js:16:56)
    at functions/[[path]].js (/Users/test/project-name/functions/[[path]].js:4:1)
    at __init (/var/folders/3s/74fw0j915232w50ctbnxyg7c0000gn/T/functionsWorker.js:16:56)

Here's a different approach: https://github.com/BenoitAverty/remix-i18n-test/blob/master/app/lib/i18n.server.ts
But keep in mind that Remix can run on Cloudflare Workers, whereas CloudFront is just a CDN (serves static content but cannot server-side render).

I suppose by Cloudfront you mean Cloudflare? I want to add support for Cloudflare, for now you can import directly from the built files so they FileSystemBackend is not included.

oh i was confused. i meant cloudflare.

Since v4.0.0, there's nothing in the library core that requires Node.js modules, so it should work just fine in Cloudflare.


Standardize the service and control methods.

Service and control methods to perform CRUD operations on projects and issues are written with different verbs as prefix, such as findBysomething, getSomething, createSomething. The verbs vary with objects, for example, update methods for users starts with update or edit in some cases. Therefore, for a more readable code, standardize the name of the method according to their action is a good practice.

Commit df02b7cdd2eeeee21264ddb445bd465fc26c1d04 standardize all the methods.


Unable to support dynamic field names

Versions:

VueJs: 2.3.3
Vee-Validate: 2.0.0 RC 18

Description:
Field names are not dynamic. Changing a field name after the v-validate directive has initialized does not reflect in the error message.
Steps To Reproduce:
See https://jsfiddle.net/dfmelicor/160yxgts/6/.
Change the field name and click "Validate". The error message still uses the old field name.

This is not a bug, this is by design. Some attributes must remain static, one of which is the field name. One of the reasons that it would break any custom errors added in the error bag since the field id is not available easily because it is generated internally.
Now, it is possible to change the field name with undocumented internal API like this:
https://jsfiddle.net/mzyugfd1/
However I don't see any benefits of allowing the field name to be dynamic, since the errorbag errors will also require updating after the field name changes, so you are doing 1 extra validation just to generate those messages.
On top of that you can just assign a dynamic alias using data-vv-as and it would do the job just fine, but would still require another validation to refresh the messages.
https://jsfiddle.net/918tjsyx/1/
Feel free to suggest scenarios where it would be imperative to allow the field name to be dynamic.

So I've created a simple '' component.
What would be the best approach to apply the key to the name attr on the <input>, it only needs to be bound once and not dynamically updated.

In your app-field.vue You can leverage the component options to make vee-validate figure the name automatically.
export default {
 name: 'AppField',
 props: {
  name: String
 },
 $_veeValidate: {
   name () {
     return this.name; // the prop value.
   }
 }
}

Read more about it here: https://baianat.github.io/vee-validate/concepts/components.html#component-constructor-options

Let's say I have a div that iterates over a given array of JSON objects:
[{name:"me",job:"programmer",age:"whoCares"},{name:"you",job:"whatever",age:"veryOld"}]

<input :id=name+index :name=name+index v-validate=required/>
{{errors.first(name+index)}}
<input id=job+index :name=job+index v-validate=required/>
{{errors.first(job+index)}}
<input id=age+index :name=age+index v-validate=required|numeric/>
{{errors.first(age+index)}}

<button id=addMoreItems /> // adds a blank object to the array and thus another set of inputs requiring validation
It results in an error message like: "The name1 field is required."
Would that be a suitable reason to override dynamically generated name attributes?


Add functionality to collect metrics/statistics across multi-subject tests

Background context

Intervertebral disc detection and labeling

PR #2679 modifies the approach that  sct_label_vertebrae uses. The new approach has only been tested lightly (a few single-subject tests, comparing results qualitatively).
The approach will be modified again in the future (i.e. with DL c2/c3 detection)
Spine intervertebral disc labeling using a fully convolutional redundant counting model (Rouhier et al., 2020) compared disc labeling approaches quantitatively across multiple subjects. It used custom scripts to collect and aggregate the data, but AFAIK that work can't be reused for #2679.

Problem description

When a modified algorithm is proposed for SCT, it would be useful to perform quantitative, multi-subject comparisons between the modified approach and the existing approach.
Right now SCT researchers/developers must create a custom script (or Jupyter notebook) outside of SCT to extract metrics and aggregate them across batches of subjects.
Custom scripts like these are commonly written for one-time use, so they are often not (a) repeatable or (b) documented well.
Having built-in functionality could help with both of these problems.

Potential solutions

SCT currently has sct_run_batch for processing data across multiple subjects using a single command. So, perhaps there could be a way for sct_run_batch to return per-subject metrics across the batch in a nicely formatted table.
@jcohenadad had thoughts about this (to be shared after this issue is created), see https://github.com/neuropoly/spinalcordtoolbox/pull/2679#issuecomment-706361082

So, I'm not sure what would be best to do. The bottomline, as nicely described by @joshuacwnewton in this issue body, is that we need to document results if we introduce/modify an existing behaviour. So here are the possibilities:

we create a specific repos under https://github.com/sct-pipeline dedicated to a specific change, e.g. as was done for sct_deepseg_sc here
we document everything in the PR of the proposed change: upload the scripts, results and figures

feedback welcome 😊

I like the idea for the dedicated repo as I think adding everything in the PR could be a bit more messy. One idea for the codebase could be to retrieve all coordinates from the labels-disc files and put them in a CSV (the first column would be the name of the subject, the second would be the coordinates for C2/C3, the third one would be the coordinates for C3/C4, and so on .. ). That way we can keep those file. We can run the prediction on data multi-subject, with sct_run_batch.
The idea would be:

Get ground truth coordinates in a CSV (let's call it CSV_gt) (using our new custom made function)
Run prediction with "old" method
Get prediction results in the CSV (Let's call it CSV_old)
Run prediction with the new methods
Get results in a CSV. (let's call it CSV_new)
Compare CSV_old and CSV_new to CSV_gt.

I think that if a user is interested he could use these functions (the one that retrieves the predicted coordinates in a CSV and the one comparing CSV) to see if that changes anything for him and one which subjects. He could compare the old approach and the new approach on his own dataset.

Good start, a few comments:

in order to be able to compare old vs. new behaviour, we need to compare the same outputs. Hence, labels-disc will not work (because these are posterior disc labels, which are not output by old function). Instead, we should use the disc level output of sct_label_vertebrae, i.e. XXX_segmentation_labeled-disc.nii.gz. These labels are positioned in the middle of the spinal cord (ie: correspond to the interface between two vertebral levels).
the ground truth are positioned in the anterior disc, so they need to be projected on the spinal cord, for further comparison. In order to do that, we could use: sct_label_vertebrae -discfile.
we could then do a label-wise MSE with sct_label_utils -MSE, comparing candidate with the ground truth.

@jcohenadad @joshuacwnewton I think I have a "first version" ready on the repo  https://github.com/sct-pipeline/vertebral-labeling-validation, Feel free to open an issue about any question you might have.

@jcohenadad @joshuacwnewton I think I have a "first version" ready on the repo https://github.com/sct-pipeline/vertebral-labeling-validation, Feel free to open an issue about any question you might have.

feedback added: https://github.com/sct-pipeline/vertebral-labeling-validation/issues


Satt 68 part2

Description
Part 2 on Drupal 10.3 & platform config update
Part 1 #575

I will create a new branch


Does ceresDB support prometehus remote_write data input ?

Description

Does ceresDB support prometehus remote_write data input?
https://prometheus.io/docs/prometheus/latest/configuration/configuration/?spm=a2c63.p383<IP_ADDRESS>c73743dfdpdeF#remote_write
Proposal

Additional context

We are considering implementing CeresDB as Prometheus remote storage. @waynexia will provide an RFC.

I'm drafting a proposal but it's mainly about remote read. Writable storage may come later. Though it's not planned in present, it should not be very different from the read path.

I'm drafting a proposal but it's mainly about remote read. Writable storage may come later. Though it's not planned in present, it should not be very different from the read path.

OK, thanks for reply!
And i have another question about the performance about ceresDB, Is there a performance test report comparing influxDB /clickhouse/druid...?

Hi, the project is still in rapid development, so we haven't done much benchmark work.
BTW, I would like to know what features do you care most for a Prometheus remote storage?

Hi, the project is still in rapid development, so we haven't done much benchmark work.
BTW, I would like to know what features do you care most for a Prometheus remote storage?

OK,  i see.
For a prometheus storage, the most thing i care about is the performance, And can be compatible with prometheus query and write protocol.


Component Button - Secondary Outline Mini Right Icon variant not visible

Does a discussion already exist on the topic you are interested in, or on a similar topic?

[X] I verified and it doesn't exist

What
The variant of Button / Secondary Outline / Mini / Text + Right Icon is not visible in the asset list. This is caused by the fact that the component has the same name as the Small version Button / Secondary Outline / Small / Text + Right Icon.
Why
The location of the component in the asset list is incorrect, and therefore difficult to find.
Context
No response
More
No response

Thanks for the report @Ludovik95 , the issue has been fixed and it'll be available in the next release (this week) 🙌


Complex URL patterns

The documentation needs to up updated from:
// routes/x.ts
import { RouteConfig } from "$fresh/runtime.ts";
const config: RouteConfig = {
routeOverride: "/x/:module@:version/:path*",
};
to
import { HandlerContext, RouteConfig } from "$fresh/server.ts"; // update path
export const config: RouteConfig = { // must be exported
routeOverride: "/api/db/:resource(jobs?|bar)/:id(\d+)?", // example using a more complex pattern
};
Also when I tried to perform deno test.  The test cases failed with many TS2300 [ERROR]:.  The solution for me was to add the following to the test code.
/// <reference no-default-lib="true"/>
/// <reference lib="dom" />
/// <reference lib="deno.ns" />
/// <reference lib="deno.unstable" />

import { RouteConfig } from "$fresh/server.ts"
export const config: RouteConfig = {
   routeOverride: "/api/db/:resource(jobs?|bar)/:id(\d+)?",
};

I don't really understand how this route config is supposed to work. I have tried the following routes and they don't work.

http://localhost:8000/api/db/bar/1
http://localhost:8000/api/db/jobs/1
http://localhost:8000/api/db/job/1

Am I doing something wrong?


Pin GitHub Actions to digests

Hey there 👋
I work on an open source security project (Frizbee) that can automatically pin GitHub Actions to digests (instead of floating tags).
The Frizbee team is trying to spread the word to open source maintainers about the need for this, because pinning your actions to commit hashes is the only way to get an immutable pointer to a specific revision. If an action's source code repo is compromised by a malicious actor, you'll still be referencing a known-good version and your project won't be at risk.
If you want to implement actions pinning, here's how you can easily do this with Frizbee (to avoid having to manually look up the digest for each tag or branch):

Install the Frizbee CLI by following these instructions
Use the frizbee actions command to parse all of your Actions workflows and replace the needed tags with the commit checksum
Done!

Note: Dependabot supports updating pinned actions and will continue to update them. For convenience, Frizbee appends a comment with the version of this action.
If it's easier for you, I can go ahead and create a PR for the above steps. I wanted to make sure this was something you'd want to move forward with first before doing that.

Thanks for the suggestion, looks like a good idea I'll get on this.


How can i get token from web browser

can i get token from web browser,i test it but get 401 unauthorized，thanks

No, you can't. You have to send Authorization header with bearer token somehow. Use Postman, cURL ... or write javascript app to store and send token.


Change config items

#8

I have fixed these items and pushed them to this branch, but I'm not sure if I need to do anything to add them to this pull request!


Disable posting new issues if there are consecutive successful report.

The update is to include all workflows, including Segmentation and other workflows not included in the first page, which has 30 workflows by default.


Problems when subscriptions complete

Hi,
I was encountering issues when using multiple subscriptions in my application (using graphql-transport-ws subProtocol).
SimpleGraphQLClient is (by design) using a single Websocket instance for all running subscriptions.
However, when a running subscription is unsubscribed (the graphql server will handle this request with a stop/complete payload), the WebSocketUpdate breaks (https://github.com/LastAbyss/SimpleGraphQL-For-Unity/blob/master/Runtime/SimpleGraphQL/HttpUtils.cs#L368), and no further payloads are being processed anymore, so other subscriptions don't receive any updates.
I suggest to just continue the loop, when a subscription completes/ends. Or would this harm performance?
Another suggestion is to track the running subscriptions, and disconnect (dispose) the single web socket as soon as all subscriptions where unsubscribed again. When opening a new subscription afterwards, this would reopen a new connection, and restart the update cycle.
What do you think?

I like your second solution to this problem. I think it's necessary to implement since we should implement the behavior for the stop payload on websocket disconnects as well.
WebSocketUpdate should only break when there are zero active subscriptions left, and I believe all we need is a simple counter that increments/decrements on start/stop of subscriptions.
The stop behavior just needs to continue, since the server only sends a complete when the connection is done (correct me if I'm wrong here), yeah?

I’ll submit a PR tomorrow to fix this, using a counter to represent active subscriptions and do a proper disconnect hen no active subscriptions left.
For the stop command, I don’t completely understand what you mean. Maybe this confusion relates to the difference of subprotocols. For graphql-transport-ws subprotocol there is no stop type payload, only a (bidirectional) complete: https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md#complete

I suppose I was going by your statement where you mention "stop/complete" payload:

However, when a running subscription is unsubscribed (the graphql server will handle this request with a stop/complete payload), the WebSocketUpdate breaks...(cont)

I saw that we submit a "stop" payload on non graphql-transport-ws, but don't check for it here:
https://github.com/LastAbyss/SimpleGraphQL-For-Unity/blob/1e987605ca452ec62dd142b36a26b8f208257819/Runtime/SimpleGraphQL/HttpUtils.cs#L365
Not sure if that's a problem for our use case (I haven't used this library in quite some time).

I guess that the stop command (client->server) and complete (server->client) response are unidirectional in graphql-ws subprotocol, since I haven't changed the response payload processing when introducing graphql-transport-ws (https://github.com/LastAbyss/SimpleGraphQL-For-Unity/pull/37/files). But I can't seem to find any published info about this online...

In that case, we're OK to move forward as is. I was just concerned that we might've forgotten something that would cause a bug later. I also searched for documentation on it, and it's pretty sparse... but I haven't seen anyone complain about it thus far, so I think it's alright to leave it alone.
Feel free to proceed with your PR as you wish, and I'll give it a look whenever you're ready!

PR done! Please give it a look. Thx!
#43

Gave it a look, looks great! Just needs a couple of edits and it should be good to go.

Thanks a lot, Pieter! I appreciate your work on this! 😄


Tests @bounty $100 tokens

Coverage 70-80%

Hey do I can look into this? Would  need a bit more information.

@LevisNgigi @yadavshubham01 Thanks for being interested in participating. However, at the moment, the issues are available only to core members. As soon as possible, we will open our project to all contributors.


Is there a way to only render a certain area of the map?

This is not an issue and more of a question from a novice (title). I'm trying to make a lost/found web app which involves displaying my school's map. I think it's unnecessary to render the rest of the surrounding locations as it requires more bandwidth. Is there any way to do this? I've also set maxBoundary to within my campus only.
Thanks in advance!!!

Hi, great to hear that you find Leaflet useful!
However, this issue tracker is used for reporting bugs and discussing new features. For questions on using Leaflet, please use gis.stackexchange.com or stackoverflow.
If you are really sure that this is a bug in leaflet, or a feature request, please change the wording to make it look like a bug report.

Also please note that there is no maxBoundary option. There's maxBounds for L.Map and for L.TileLayers. Read the API documentation. Experiment with both.

Note that there's also a plugin to do this: https://github.com/aparshin/leaflet-boundary-canvas
See the demo: http://aparshin.github.com/leaflet-boundary-canvas/examples/canvas-boundary-edit.html
However I don't think it will save that much tile loading work, compared to just setting a tight maxBounds.


Why 2OpenHashMap ergodic performance is not as good as java.util.HashMap

When I test large-capacity map traversal, the performance is several times worse than that of java.util.HashMap.
Code:

Int2IntLinkedOpenHashMap = new Int2IntLinkedOpenHashMap (1024*1024);
for
(int i = 0; i < 1024 * 64; i + +) {
map.put (i, i);
}
for (int i = 0; i < 100; i + +) {
// For (Int2IntMap. Entry entry: map. int2IntEntrySet (){
for (int key: map. keySet (){
}

If you create a map with more than a million slots and then put in 65536 integers, yes, it'll be slow. Why would you do that, it's the real question.


Use v4 tables for samples and time series

@ankitnayan PTAL

Also, we cannot use cumulativetodeltaprocessor for all metrics ingested to our otel-collectors as promql queries won't work with delta right?

Is the runTimeSeriesReloader loader needed anymore?
It caused the OOM earlier. There should be some elaborative way to address that but it's a independent work.

Also, we cannot use cumulativetodeltaprocessor for all metrics ingested to our otel-collectors as promql queries won't work with delta right?

Yes, relying on PromQL is the last thing we want users to do. They are slower and more expensive. It's the worst of both of worlds (neither as good as Prometheus or ClickHouse) to try to remain fully PromQL compatible and ClickHouse. There are two metric types where temporality comes into the picture 1. Histogram 2. Counter and use cases are mostly known with these two, almost every query has some sort of (sum|avg|min|max)(rate|increase) all of which we support in the builder. If there is something we can't support, we will try to make it happen.


I cannot run the Desktop app repeatedly

Homework

[X] I took the time to write a good, descriptive issue title
[X] I read nativefier --help and API.md.
[X] I checked CATALOG.md for community suggestions & workarounds.
[X] I searched existing issues, open & closed. Yes, my bug is new.
[X] I'm running the latest version.

Nativefier command

nativefier 'localhost:7042'

Steps to reproduce
I have built the Desktop app, run it - it works fine.
But after it: run, exit, run, exit, run and see "Loading..." only in the main window and cannot run the app again as a full functional app.
What I do wrong?
Expected behavior
It should be run repeatedly
Actual behavior
I have built the Desktop app, run it - it works fine.
But after it: run, exit, run, exit, run and see "Loading..." only in the main window and cannot run the app again as a full functional app.
Debug info
No response
Nativefier version
49.01
Node.js version
v16.16.0
npm version
8.19.2
OS
Windows 10

Additional info about miracles:

I have made my Blazor site in VS 2022.

nativefier 'https://localhost:7062'

If I run in the VS the site, Opera appears with site then I run the Desktop app it can be run repeatedly, not always but can be
If VS is closed then I cannot run app.exe : it appears as an app with blank window
I run VS again and run the site. Now app.exe can be run

I think this may be a misunderstanding of what Nativefier does. Nativefier does not save a copy of the site you pass to it in the app. It essentially just runs as a web browser that only serves one page (the one you pass to it).
Therefore if the web site you pass it goes away (such as when you close Visual Studio, which is running as your web server), then the app will no longer be able to access the page. Thus you'll only see "Loading" as it attempts to, unsuccessfully, contact the web server that is not there anymore.
Closing as this is all by design. If you think I'm misunderstanding your situation, you can provide more context and we may reopen.

Oh, I thought it works like Electron.NET - builds Desktop app independent on the source site.
But how to be: I want to create Desktop app from a site and provide it to my customer. He has the app-> db server, i.e. all what he needs to work. I should provide web site too?

Any answers? thank you


Update go-macaron/session to latest mast to fix RCE-bug

Should fix https://github.com/go-gitea/gitea/issues/5140

Please send back port to release/v1.6 and release/v1.5


Input to classifer

Hey @yhenon,
Awesome work on the repo.
Correct me if I am wrong, shouldnt input to classifer here(https://github.com/yhenon/keras-frcnn/blob/master/train_frcnn.py#L71) be output from rpn?
Thank You,
Pradyumna.

Hi,
Sorry I took so long - the input to the classifier is indeed the output from RPN. But we want to propagate the gradient through all the layers of the network when training the classifier, so we pass the image and calculate the whole thing.


chore(mint-client): test parallel spends and reissuances

Fixes #3988. Note that using MemDatabase still leads to deadlocks, but that's not production-ready anyway, so we can track it independently.

I wonder why the linter didn't fail on the PR, will fix tomorrow.

I wonder why the linter didn't fail on the PR, will fix tomorrow.

Landed after  what your change is on top of, I guess.

@elsirion We land?

There actually was something to fix.

@elsirion Still seems to be. :D

Yeah, forgot to run clippy with the extra command line options …


LLVM version error during EOS install

Hi,
I came across LLVM error while installing EOS.  EOS requires LLVM 4.x, while Homebrew provides 6.x for Mac OSX HighSierra.  I do export the LLVM_DIR and it does not work.  When I use homebrew to check LLVM info, it shows only LLVM 6.0, while LLVM 4.x is another package LLVM@4.
Error message:
CMake Error at libraries/wasm-jit/Source/Runtime/CMakeLists.txt:26 (find_package):
  Could not find a package configuration file provided by "LLVM" (requested
  version 4.0) with any of the following names:

    LLVMConfig.cmake
    llvm-config.cmake

  Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
  "LLVM_DIR" to a directory containing one of the above files.  If "LLVM"
  provides a separate development package or SDK, be sure it has been
  installed.

@bladexxv EOS.IO requires LLVM 4 to compile successfully.
On Mac OS using homebrew you would need to do the following (the build script will handle installing  the proper LLVM version.)
brew remove --force llvm
cd /path/to/eos
git rm -rf build/
git pull
git submodule update --init --recursive
./eosio_build.sh
To verify the LLVM install after running the build script you can run:
$ ls -lah /usr/local/bin/llvm-config
lrwxr-xr-x  1 billhamilton  admin    38B Jan 19 04:52 /usr/local/bin/llvm-config -><EMAIL_ADDRESS>$ /usr/local/bin/llvm-config --has-rtti --version
YES
4.0.1

Hi @pacificcode  thanks for comment. I tried your approach and it still did not work out -- the main issue is LLVM version that build.sh is always trying to find LLVM 4.0 package but did not find.

not work, problem still exist

http://www.softwareace.cn/?p=1757

http://www.softwareace.cn/?p=1771

Clean
First off, make sure you clean your build folder by running rm -rf build/.
Pull
Then, pull the latest updates:
git pull
git submodule update --init --recursive

Install LLVM 4
Follow instructions from #43 to make sure you have the correct version of llvm (which is 4) and you have set the LLVM_DIR environment variable. Note: Homebrew now uses llvm@4 in /usr/local/Cellar.

Hi,
I also have the same error and do not know how to solve it


iam_assume_role_session_name and iam_assume_role_duration for aws authentication.

For iam_assume_role_duration,
Currently AWS provides upto 12h maximum duration where the generated session credentials are valid. But in terragrunt, this attribute seems to be accepting only till 1 hour. Is there a way you can allow to meet the maximum duration allowed by AWS?
For iam_assume_role_session_name,
We currently have a condition on the assume role policy that only a valid IAM user can assume the role, and we have multiple IAM Users who executes the terragrunt code. Is there a way that we can dynamically assign valid IAM user names to this attribute like from get caller identity?

Hi,
AFAIK, currently is supported only iam_assume_role_duration or CLI argument --terragrunt-iam-assume-role-duration
References:
https://terragrunt.gruntwork.io/docs/reference/cli-options/#terragrunt-iam-assume-role-duration
https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attributes/#iam_assume_role_duration

thank you. Duration is not a huge problem.
But how about iam_assume_role_session_name ? Is there a solution to pass the usernames dynamically while init/plan/apply to the iam role? There is a condition in my case that only a valid iam user can assume the role(like below), and I do not want to hardcode the username iam_assume_role_session_name as there are many who contributes to the code.
{
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:RoleSessionName": "${aws:username}"
}
}

Can anyone confirm if the above is actually possible with terragrunt?


Check user permissions and metadata every CMS load.

- Summary
Fixes #556.
Before, if the CMS was loading user OAuth credentials from localStorage, then user write access would not be checked again. However, the config.yml repo could be changed, which would cause the user to be still logged in even if they did not have write permissions. Also, if the user had updated their metadata (avatar, etc.), the CMS would not update that either.
The main change that this PR makes is that it expects setUser to return a rehydrated user object, instead of just taking the user object that it was fed and using it.
- Test plan

[x] GitHub backend
[x] test-repo backend
[x] git-gateway backend

- Description for the changelog
Check user permissions and metadata every CMS load.

This also needs fixed in the case that the backend gets switched and the CMS is reloaded. @Benaiah what do you think about just saving the backend value into localStorage as part of the user value, then the CMS checks if it is the right user for the backend being used?

@erquhart @Benaiah changes should be addressed or explained. Also, I'm not sure if I explained it adequately -- the main change that this PR makes is that it expects setUser to return a rehydrated user object, instead of just taking the user object that it was fed and using it.


Save files to disk for NDN-DPDK fileserver

@sankalpatimilsina12 Can you create this pull request against ndn-hydra-dpdk branch?

Also, please split the commit into multiple commits - the ones that are onyly for DPDK should be a seperate commit. The ones that need to be merged with master will be another commit.


Improving UI resolution scaling for SPI Display and Accelerometer samples

Hi @dankuo, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;


Failing test case for waiting on a reused FD.

Types of Changes

Failing test case.

Contribution

[x] I added tests for my changes.
[x] I tested my changes locally.
[x] I agree to the Developer's Certificate of Origin 1.1.

Notes
I think I found another problem. Probably related to the "lazy disarming" optimization.
IIUC, the selector can mistakenly assume that events for a certain FD are already being polled, but they aren't because the FD has been closed and reopened since last time.
The test case works if you comment out local.close.
I think it's triggering some other problem I was investigating, but not sure...

IIUC, the selector can mistakenly assume that events for a certain FD are already being polled, but they aren't because the FD has been closed and reopened since last time.

Yeah, I saw some code in libev which was trying to work around this.


Optimize Ansible Install Script

Solved the problem of installing different ansible versions will fail。
modify the file install_ansible.sh

remove old ansible before install a new one
apt-get remove -y ansible
apt-get purge -y ansible
remove the PPA associated with the old version
sudo add-apt-repository -r ppa:ansible/ansible-2.4

Hi @lijuncloud , please resove the conflicts above, thx!


migrations in modules

I have 2 migrations. First is located in @app/migrations second @app/modules/modName/migrations
to apply them I run two command:
php yii migrate/up and php yii migrate/up --migrationPath=@app/modules/modName/migrations
but I can't rollback them like:
php yii migrate/down 2 or php yii migrate/down --migrationPath=@app/modules/modName/migrations
I think migration/down should keep path or module name to migration files for a transparency rollback.

Add your module's namespace to migrations in consol/config/main.php


Add: Canal 79 Puan

Channel Name
Canal 79 Puan
Alternative Names (optional)
No response
Network (optional)
No response
Owners (optional)
No response
Country
AR
Subdivision (optional)
No response
City (optional)
Puan
Broadcast Area
c/AR
Languages
esp
Categories (optional)
general
NSFW
FALSE
Launched (optional)
No response
Closed (optional)
No response
Replaced By (optional)
No response
Website (optional)
https://canal79tv.com.ar/
Logo
https://canal79tv.com.ar/wp-content/uploads/2021/06/canal_79_gif.gif
Notes
No response

https://iptv-org.github.io/channel?id=Canal79Puan.ar


Metastore FQDNs in East US 2 have the same IP Address

The East US 2 Metastore FQDNs resolve to the same IP Address
consolidated-eastus2-prod-metastore.mysql.database.azure.com
consolidated-eastus2-prod-metastore-addl-1.mysql.database.azure.com
both resolve to <IP_ADDRESS>
User Defined Routes in Azure cannot have duplicate Route Prefixes, so this will fail

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

ID: a44cbeaf-af2c-ef7e-b411-24556279d898
Version Independent ID: aaced3ee-7d7c-a9d6-a81b-b132674fa055
Content: User-Defined Route Settings for Azure Databricks - Azure Databricks
Content Source: databricks/administration-guide/cloud-configurations/azure/udr.md
Service: azure-databricks
GitHub Login: @mamccrea
Microsoft Alias: mamccrea

Thank you for your detailed feedback.  We are looking into the issue, and we will respond when we have more information.

Thank you for bringing this to our attention.  I have noticed that both westus2 metastores resolve to <IP_ADDRESS>
eastus metastore and westus metastore do not appear to have this issue.  Only those ending in 2 appear to have this issue.
I will reach out internally for more information.

You only need to implement one of the URL's not both, @phrayze .  Still investigating why both are present in the doc.

@mamccrea I have not received any responses to my internal escalations, so I am forced to assign the issue to you.  I have pinged you in teams to give you visibility to my escalation.

I have opened a ticket to address this issue.

Thank you.  I will ping you offline to get the ticket info.


[specfile] prevent segfault when file is not a spec file

Test for presence of #S or #F at the beginning of the file before opening the file.
Closes #424

Fine :-)


HBASE-24759 Refuse to update configuration of default group

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 30s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 36s
master passed

+1 :green_heart:
checkstyle
1m 29s
master passed

+1 :green_heart:
spotbugs
2m 40s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 21s
the patch passed

+1 :green_heart:
checkstyle
1m 26s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
11m 19s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
2m 59s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 27s
The patch does not generate ASF License warnings.

35m 48s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2126/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux babc727a0286 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 8191fbdd7d

Max. process+thread count
94 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m  4s
the patch passed

+1 :green_heart:
compile
1m 29s
the patch passed

+1 :green_heart:
javac
1m 29s
the patch passed

+1 :green_heart:
shadedjars
5m 45s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 19s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 39s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m 31s
hbase-common in the patch passed.

+1 :green_heart:
unit
131m 50s
hbase-server in the patch passed.

161m 32s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2126/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux a28da9d3a1e3 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 8191fbdd7d

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2126/1/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2126/1/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2126/1/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2126/1/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2126/1/testReport/

Max. process+thread count
4299 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2126/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 28s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 34s
master passed

+1 :green_heart:
compile
1m 18s
master passed

+1 :green_heart:
shadedjars
5m 35s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 59s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 26s
the patch passed

+1 :green_heart:
compile
1m 16s
the patch passed

+1 :green_heart:
javac
1m 16s
the patch passed

+1 :green_heart:
shadedjars
5m 34s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 58s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 22s
hbase-common in the patch passed.

+1 :green_heart:
unit
153m 18s
hbase-server in the patch passed.

180m 43s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2126/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 08eb90886ca5 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 8191fbdd7d

Default Java
1.8.0_232

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2126/1/testReport/

Max. process+thread count
3997 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2126/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 28s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 22s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 39s
master passed

+1 :green_heart:
checkstyle
1m 27s
master passed

+1 :green_heart:
spotbugs
2m 42s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 21s
the patch passed

+1 :green_heart:
checkstyle
1m 28s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
11m 10s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
2m 59s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 27s
The patch does not generate ASF License warnings.

35m 46s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/4/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux ad219ae44d91 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 047e0618d2

Max. process+thread count
94 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/4/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 42s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 43s
master passed

+1 :green_heart:
compile
1m 20s
master passed

+1 :green_heart:
shadedjars
6m 48s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  1s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 28s
the patch passed

+1 :green_heart:
compile
1m 18s
the patch passed

+1 :green_heart:
javac
1m 18s
the patch passed

+1 :green_heart:
shadedjars
6m 27s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  0s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 22s
hbase-common in the patch passed.

+1 :green_heart:
unit
140m 31s
hbase-server in the patch passed.

170m 36s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/4/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 22f2c5ab8083 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 047e0618d2

Default Java
1.8.0_232

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/4/testReport/

Max. process+thread count
4249 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 53s
the patch passed

+1 :green_heart:
compile
1m 51s
the patch passed

+1 :green_heart:
javac
1m 51s
the patch passed

+1 :green_heart:
shadedjars
8m 16s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 20s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 46s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
2m 16s
hbase-common in the patch passed.

+1 :green_heart:
unit
212m 45s
hbase-server in the patch passed.

250m 38s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/4/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 9d0ab214feeb 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 047e0618d2

Default Java
2020-01-14

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/4/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/4/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/4/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/4/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/4/testReport/

Max. process+thread count
2819 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/4/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 17s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 22s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 42s
master passed

+1 :green_heart:
checkstyle
1m 29s
master passed

+1 :green_heart:
spotbugs
2m 43s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 25s
the patch passed

+1 :green_heart:
checkstyle
1m 25s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
11m 13s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
2m 58s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 26s
The patch does not generate ASF License warnings.

36m 39s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/5/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux aea96f58b452 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 7909e29de5

Max. process+thread count
94 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/5/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 27s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 26s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 40s
master passed

+1 :green_heart:
compile
1m 19s
master passed

+1 :green_heart:
shadedjars
6m 23s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 59s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 26s
the patch passed

+1 :green_heart:
compile
1m 18s
the patch passed

+1 :green_heart:
javac
1m 18s
the patch passed

+1 :green_heart:
shadedjars
6m 28s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 57s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 14s
hbase-common in the patch passed.

+1 :green_heart:
unit
140m 32s
hbase-server in the patch passed.

169m 50s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/5/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 8640e7712355 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 7909e29de5

Default Java
1.8.0_232

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/5/testReport/

Max. process+thread count
4492 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 24s
the patch passed

+1 :green_heart:
compile
1m 35s
the patch passed

+1 :green_heart:
javac
1m 35s
the patch passed

+1 :green_heart:
shadedjars
7m 17s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 15s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 40s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m 46s
hbase-common in the patch passed.

+1 :green_heart:
unit
189m 20s
hbase-server in the patch passed.

222m 34s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/5/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux cfab5c0bdd8d 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 7909e29de5

Default Java
2020-01-14

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/5/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/5/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/5/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/5/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/5/testReport/

Max. process+thread count
2896 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/5/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 20s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 32s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 31s
master passed

+1 :green_heart:
checkstyle
1m 27s
master passed

+1 :green_heart:
spotbugs
2m 39s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 22s
the patch passed

+1 :green_heart:
checkstyle
1m 25s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
11m 15s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
3m  3s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 25s
The patch does not generate ASF License warnings.

36m 41s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/6/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 0f207290bc64 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 979edfe720

Max. process+thread count
94 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/6/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 27s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 37s
master passed

+1 :green_heart:
compile
1m 20s
master passed

+1 :green_heart:
shadedjars
6m 33s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 57s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 29s
the patch passed

+1 :green_heart:
compile
1m 18s
the patch passed

+1 :green_heart:
javac
1m 18s
the patch passed

+1 :green_heart:
shadedjars
6m 31s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 58s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 21s
hbase-common in the patch passed.

+1 :green_heart:
unit
140m 47s
hbase-server in the patch passed.

170m 26s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/6/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 8d92a16b62d2 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 979edfe720

Default Java
1.8.0_232

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/6/testReport/

Max. process+thread count
3885 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 31s
the patch passed

+1 :green_heart:
compile
1m 34s
the patch passed

+1 :green_heart:
javac
1m 34s
the patch passed

+1 :green_heart:
shadedjars
7m 13s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 15s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 40s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m 46s
hbase-common in the patch passed.

-1 :x:
unit
196m 45s
hbase-server in the patch failed.

231m  3s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/6/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux ba0af86f3acd 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 979edfe720

Default Java
2020-01-14

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/6/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/6/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/6/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/6/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/6/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/6/testReport/

Max. process+thread count
3426 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/6/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 18s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 32s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 30s
master passed

+1 :green_heart:
checkstyle
1m 27s
master passed

+1 :green_heart:
spotbugs
2m 40s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 24s
the patch passed

+1 :green_heart:
checkstyle
1m 26s
the patch passed

+1 :green_heart:
whitespace
0m  1s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
11m 13s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
2m 58s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 25s
The patch does not generate ASF License warnings.

36m 33s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/7/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux c6738ea0a7bc 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 85a174f5b3

Max. process+thread count
94 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/7/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 28s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 24s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 40s
master passed

+1 :green_heart:
compile
1m 20s
master passed

+1 :green_heart:
shadedjars
6m 32s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  1s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 25s
the patch passed

+1 :green_heart:
compile
1m 19s
the patch passed

+1 :green_heart:
javac
1m 19s
the patch passed

+1 :green_heart:
shadedjars
6m 35s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 57s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 14s
hbase-common in the patch passed.

+1 :green_heart:
unit
138m 50s
hbase-server in the patch passed.

168m 26s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/7/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 109e597a4c98 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 85a174f5b3

Default Java
1.8.0_232

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/7/testReport/

Max. process+thread count
4287 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 24s
the patch passed

+1 :green_heart:
compile
1m 36s
the patch passed

+1 :green_heart:
javac
1m 36s
the patch passed

+1 :green_heart:
shadedjars
7m 18s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 16s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 40s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m 46s
hbase-common in the patch passed.

+1 :green_heart:
unit
189m 16s
hbase-server in the patch passed.

223m  4s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/7/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2126

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux c9d7104e3589 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 85a174f5b3

Default Java
2020-01-14

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/7/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/7/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/7/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/7/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/7/testReport/

Max. process+thread count
3315 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2126/7/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.


Enchanting Courtesan spell level

Hello,
I'm theorycrafting a succubus-like character and have a question about Enchanting Courtesan spell level (checking it in Spellbook).
When I pick first level in Enchanting Courtesan, my spell level stays the same. If I pick, for example, Loremaster level, it increases normally. My starting class is Thessalonian Specialist (Lust) if this matters.
Is it how pathfinder system works or a bug?

Aha, it looks like your implementation is correct https://www.aonprd.com/PrestigeClassesDisplay.aspx?ItemName=Enchanting Courtesan But even without 1 caster level the build looks solid, with Hideous laughter + Best Jokes


BCFIPS 2.0 StackOverflowError when loading com.sun.jna.Native

We are trying to upgrade of BCFIPS <IP_ADDRESS> to BCFIPS 2.0.0, and immediately run into the issue before. Our Java service uses the BouncyCastleFipsProvider to be FIPS compliant. Our java.security file has the following line.
security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
securerandom.source=file:/dev/random
This happens if the securerandom.strongAlgorithms is missing or set to DEFAULT:BCFIPS.
securerandom.strongAlgorithms=DEFAULT:BCFIPS
Setting it to NativePRNGBlocking:SUN will make the issue disappear, but we heard the algorithm is NOT FIPS compliant.
We are not seeing the issue with the previous version, only with the new 2.0.0 version. If anything changed, we expect there is a recommended java.security configuration to make BCFIPS 2.0 just work out of the box. However, we cannot find a documentation on how to make the configuration work.
PS: Writing a customized initialization, by bootstrapping from a default JVM SecureRandom to a FipsSecureRandom can get rid of the issue, but we are not sure that workaround is FIPS-compliant.
Everyone is expecting BCFIPS 2.0 can just work out of the box without writing a customized initalizer.
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.StackOverflowError [in thread "main"]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$1.get(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.crypto.CryptoServicesRegistrar.getSecureRandomIfSet(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.getDefaultSecureRandom(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
...
at java.base/java.security.SecureRandom.getDefaultPRNG(Unknown Source) ~[?:?]
at java.base/java.security.SecureRandom.(Unknown Source) ~[?:?]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$3.run(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$3.run(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at java.base/java.security.AccessController.doPrivileged(Unknown Source) ~[?:?]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.getCoreSecureRandom(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.access$900(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$HybridSecureRandom.(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$2.run(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$2.run(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at java.base/java.security.AccessController.doPrivileged(Unknown Source) ~[?:?]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.getDefaultEntropySource(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$1.get(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.crypto.CryptoServicesRegistrar.getSecureRandomIfSet(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.getDefaultSecureRandom(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.ProvRandom$1.createInstance(ProvRandom.java:28) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$BcService.newInstance(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at java.base/java.security.SecureRandom.getDefaultPRNG(Unknown Source) ~[?:?]
at java.base/java.security.SecureRandom.(Unknown Source) ~[?:?]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$3.run(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$3.run(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at java.base/java.security.AccessController.doPrivileged(Unknown Source) ~[?:?]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.getCoreSecureRandom(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.access$900(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$HybridSecureRandom.(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$2.run(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$2.run(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at java.base/java.security.AccessController.doPrivileged(Unknown Source) ~[?:?]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.getDefaultEntropySource(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$1.get(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.crypto.CryptoServicesRegistrar.getSecureRandomIfSet(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.getDefaultSecureRandom(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.ProvRandom$1.createInstance(ProvRandom.java:28) ~[bc-fips-2.0.0.jar:2.0.0]
at org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider$BcService.newInstance(Unknown Source) ~[bc-fips-2.0.0.jar:2.0.0]
at java.base/java.security.SecureRandom.getDefaultPRNG(Unknown Source) ~[?:?]
at java.base/java.security.SecureRandom.(Unknown Source) ~[?:?]
at java.base/java.io.File$TempDirectory.(Unknown Source) ~[?:?]
at java.base/java.io.File.createTempFile(Unknown Source) ~[?:?]
at com.sun.jna.Native.extractFromResourcePath(Native.java:1170) ~[jna-5.14.0.jar:5.14.0 (b0)]
at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1032) ~[jna-5.14.0.jar:5.14.0 (b0)]
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:1011) ~[jna-5.14.0.jar:5.14.0 (b0)]
at com.sun.jna.Native.(Native.java:221) ~[jna-5.14.0.jar:5.14.0 (b0)]
at com.sun.jna.ptr.PointerByReference.(PointerByReference.java:40) ~[jna-5.14.0.jar:5.14.0 (b0)]

securerandom.strongAlgorithms should be set to  NativePRNGBlocking:SUN, or a QRNG if you've got one - the field is used for retrieving the JVMs seed generator as an entropy source. BCFIPS is a software provider, it cannot generate it's own entropy.

@dghgit Thanks for your response, David! Can you also confirm that using "securerandom.StrongAlgorithms = NativePRNGBlocking:SUN" is FIPS compliant ?
I have also seen someone used "securerandom.strongAlgorithms=NativePRNGBlocking:SUN,DRBG:SUN", with DRBG:SUN as the second in the list. Is setting DRBG:SUN as the second in the list  an overkill or a recommendation ?

It would be good to get clarification on this. Reading online would suggest that using the SUN provider is not FIPS compliant. To be certain of FIPS compliance we would like the un-register non-FIPS providers from the JCA, but removing the SUN provider breaks BouncyCastle.

There are some things in the SUN provider which are not FIPS compliant, although as it happens it's safe to use the CertPath API and usually safe to use NativePRNGBlocking:SUN. You can remove the SUN provider providing you provide an alternative entropy source at:
securerandom.StrongAlgorithms
note: the BCFIPS provider is a software provider, putting DEFAULT:BCFIPS there will not work (it usually results in a stack overflow). We're currently experimenting with a single entropy provider based on JENT (as an example).
One further note: as SP 800-90B becomes more established, use of NativePRNGBlocking:SUN can potentially move into non-compliance if /dev/random in the underlying OS is not SP 800-90B compliant, as far as I am aware it is not a big issue right now, but it's coming.

Thanks for the response @dghgit


Init tests

[x] Implement tests for endpoints created here: https://github.com/kudos-etc/kudos-api/issues/15

Created some tests for the client library that will suffice for now: https://github.com/slashkudos/kudos-api/commit/c5b34da411805e3c66349f68e178e569c3a3d882


Incrementing the version number to 0.9.0

Checked Changelog to include relevant PRs since version increase (#76): numbered 78-83, 85-86 (#77 being an issue, #84 entry to CHANGELOG, #87 requirements related change)
Increased the required PennyLane version and PennyLane requires version number due to analytic probability api change in QubitDevice
Added a Python 3.8 check to Travis

@josh146 turned out networkx was funky for 3.5 after all on Travis :thinking:
(see rendered picture)
After a local check, reverted the pinning, but let me know if you'd suggest another solution!

:(
The next release of PennyLane will drop support for Python 3.5, so it might be safe to just remove the pinning and the 3.5 Travis job after this release of the Qiskit plugin is made. Otherwise, looks good from my end


compiler bug(?): daily release build takes 2 hours

https://buildkite.com/risingwavelabs/docker/builds/13182#0184ed58-e171-4d20-bc20-55d47cf2ce91

Normal on my laptop.

https://github.com/risingwavelabs/risingwave/pull/6159


Scatha Pet

Fixes #625
https://sky.shiiyu.moe/stats/TheBestPie/Peach

Updated the stats after the legendary screenshot, but no way to test it unfortunately :( (no player has it in inventory)

just buy it from ah smh