[PaaS] Start MongoDB on Openshift

I'd like to start MongoDb with persistent volume on OpenShift. I'd like Mongo to be accessible using MONGODB service name.
The commands I have figured out so far:
docker exec -it origin oc new-app mongo
docker exec -it origin oc expose dc mongo --generator=service/v1 --name=mongodb
docker exec -it origin oc delete svc mongo
docker exec -it origin oc volume dc/mongo --remove --confirm
docker exec -it origin oc volume dc/mongo --add --name=mongodb-data --mount-path=/data/db

Now the question is - how can I expose MongoDB outside the Kubernetes?
docker exec -it origin oc get service
NAME         CLUSTER-IP       EXTERNAL-IP   PORT(S)                 AGE
kubernetes   <IP_ADDRESS>       <none>        443/TCP,53/UDP,53/TCP   4d
mongodb      <IP_ADDRESS>   <none>        27017/TCP               33m

How can I assign external IP to the mongodb?

@rimolive Any idea how to assign external IP address to MongoDB? :)

@hekonsek, you must create a route in OpenShift with SNI passthrough. This is a link for the routes I created for A-MQ to expose all 4 protocols: https://github.com/jboss-openshift/ce-testsuite/blob/master/amq/src/test/resources/amq-routes.json
As you may know, using SNI implies using SSL/TLS protocol.
Hope that helps.

For the beginning of our migration to OS3, I propose to start MongoDB via the OS3 instance started in our PaaS script [1] (now we run MongoDB as plain Docker container). That MongoDB instance should have port 27017 exposed (temporarily), so services not migrated to OS3 should be able to access MongoDB via localhost:27017.
Can you create pull request with such change? That would be awesome for the beginning and we could continue the migration.
[1] https://github.com/rhiot/rhiot/blob/master/cloudplatform/install/rhiot-cloud-platform#L167

Based on your proposal for rhiot-cloud-platform, then we should consider check if oc command is in PATH env var. This command will be very useful because it will create the OpenShift project, add the mongodb-persistent template to it and port-forward the MongoDB ports to localhost (all I'm suggesting is based on how the script is written so far, so let me know if that's what you plan).

I propose to use dockerized OC, like docker exec -it openshift-server oc get service. We assume that Docker is installed anyway :) .

So I would say that we should replace existing MongoDB setup with the following lines:
docker exec -it origin oc new-app mongo
docker exec -it origin oc expose dc mongo --generator=service/v1 --name=mongodb
docker exec -it origin oc delete svc mongo
docker exec -it origin oc volume dc/mongo --remove --confirm
docker exec -it origin oc volume dc/mongo --add --name=mongodb-data --mount-path=/data/db

Plus, we should somehow expose MongoDB to localhost (via route I guess).
What do you think?

Yeah, that's exactly what I was thinking. But there are some things I'm doing:

I'm using the OpenShift 3 mongodb-persistent template to provision MongoDB
The oc volume command you are using seems missing something, do I did it different: oc volume dc/mongodb --add --type=emptyDir  --name=mongodb-data --overwrite. Let me know if I can use it for now

To expose the MongoDB to localhost, just run oc port-forward command. The only drawback is that you must have the pod name, which makes a bit difficult to expose via script. But I'll see what I can do. =D

Sounds cool! It's good to have somebody knowing OS better than myself :) .
Would you be so kind and shoot a pool request with an appropriate changes?

I sent https://github.com/rhiot/rhiot/pull/589, let me know if that helps.

Command for exposing port would be:
docker exec -ti openshift-server oc port-forward $(docker exec -it openshift-server oc get pod | awk 'NR>1' | awk '{print $1}' | tail -n 1) 27017

Doh! Yup, my fault. =/

No worries :)
Now I have:
EXEC : docker exec -ti openshift-server oc port-forward 27017
cannot enable tty mode on non tty input

Any idea how to handle this?

I'll see if I can find a solution for this.

Many thanks in advance. BTW Can we use routes to expose this port?

Yes, but it requires TLS passthrough to do that. That means: for MongoDB port 27017 is exposed, but outside OpenShift the port is 443.

Hmmmm, no other options for exposing ports? Only port-forward and TLS
passthrough?
śr., 11.05.2016 o 23:26 użytkownik Ricardo Martinelli de Oliveira <
<EMAIL_ADDRESS>napisał:

Yes, but it requires TLS passthrough to do that. That means: for MongoDB
port 27017 is exposed, but outside OpenShift the port is 443.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/rhiot/rhiot/issues/581#issuecomment-218595300

--
Henryk Konsek
https://linkedin.com/in/hekonsek

BTW The latest version of the script could look like:
log_info "MongoDB"
sleep 10
if [ $(docker exec -it openshift-server oc get service | grep mongo | wc -l) -eq 0 ]; then
    log_info "MongoDB doesn't exist. Creating..."
    exe docker exec -it openshift-server oc new-app mongo
    exe docker exec -it openshift-server oc expose dc mongo --generator=service/v1 --name=mongodb
    exe docker exec -it openshift-server oc delete svc mongo
fi
sleep 20
docker exec -ti openshift-server oc port-forward $(docker exec -it openshift-server oc get pod | awk 'NR>1' | awk '{print $1}' | tail -n 1) 27017 &
log_info "MongoDB started"

Unfortunately, yes. =/
The script looks good. I'm still working on the port-forward issue


GML wrapper layer

@MrEricSir Mind taking a look and seeing what you think? Nothing shocking here, mostly dumbing-down of already-available functionality.
There's a test app in demos/ that you can run on any compatible mod file.

Unless I'm missing something, no functions are exported from the DLL on Windows.  More info: https://msdn.microsoft.com/en-us/library/z4zxe9k8.aspx

@MrEricSir Huh, I had no idea you had to do that. Is that what these two files are for?
https://github.com/MrEricSir/Modipulate/blob/master/src/modipulate_lua/dllmain.cpp
https://github.com/MrEricSir/Modipulate/blob/master/src/modipulate_lua/exports.def
I'm super derpy when it comes to Windows development. Could I mimic the above files? (I assume I'd need to add any exported function to that .def file)
How does libmodipulate get away without this export table? My cup runneth over with questions.

That's weird, I wonder if one of our CMake settings auto exports all the functions? I might have to poke around later, that would be strange.

Not sure, but I'm guessing that we've never run into a problem because we haven't used libmodipulate directly in an application. We've only tested modipulate-lua as a DLL. Modipulate-osc and the demos all statically link libmodipulate, so it wouldn't have been an issue.
Anyway, as for this one, would it suffice if I imitate the dllmain and .def files from modipulate-lua?

Yeah, that should be fine. You've already set the public functions to extern C, so it's just a matter of copying all those function names into the def file.
We don't really need a DllMain at the moment, but it couldn't hurt to have.

Ok, added the exports. If DllMain isn't needed I'll skip for now, if that's alright.
Anything else before we merge?


feat(linter/eslint-plugin-promise): implement spec-only

Rule Detail:
link

Not sure what:
---- size_asserts stdout ----
thread 'size_asserts' panicked at crates/oxc_linter/src/lib.rs:50:5:
assertion failed: std::mem::size_of::<RuleEnum>() == 16

Is about?


feat(dave): from 2.0.0.a

:tada: This PR is included in version 1.10.0-prerelease.1 :tada:
The release is available on:

npm package (@prerelease dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.11.0-prerelease.1 :tada:
The release is available on:

npm package (@prerelease dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Julia agent-based modeling

https://juliadynamics.github.io/Agents.jl/stable/

Especially bacterial growth

And integration with DiffEq


Remove app-operator version label from docs and default for all workload clusters

Currently in our docs we have the version label app-operator.giantswarm.io/version: 1.0.0 which is needed or app CRs will not be processed.
This routes to a single helm 2 instance of app-operator (currently app-operator 1.0.16) which we want to retire.
We need to remove this label from our docs and ensure that app-admission-controller always defaults to the correct value for the workload cluster release.

This was done in https://github.com/giantswarm/giantswarm/issues/18349
The version label is removed from docs and we always default the correct value.


Manually change the order of the folders and files that are listed in VSCode File Explorer

Yes, this issue is a duplicate of this: https://github.com/microsoft/vscode/issues/91843
which was closed. I still wish this feature to be added. It would really make finding files easier, especially when there are a lot in the same folder. It could also follow the logical / user flow.
As a user i would like to sort my folder and files order in the explorer manually within it's parent folder, so i can decide how folders and files follow each other.
Currently it is sorted by alphanumeric, which does not follow the logicality of the project. It would make much easier to find files and understand project by looking on the logically sorted order.
Suggested implementation: drag + drop, keycombination + mouse scroll wheel.

This is a fair feature request, however we do not have it on our immediate plan. Thus assigning to backlog and we might add this in the future. Thanks

That's alright it's not on an immediate plan. I hope one day it comes thorugh. Thanks

+1 to this but my use case is more innocent. Now, I have a folder structure that looks like this:
/features
/utils
.eslintrc
.gitignore
.prettierrc
index.js
.env (gitignored)
README.md
package.json
config.json (gitignored)
package-lock.json

Imagine if it was like this:
/features
/utils
index.js
README.md
package.json
package-lock.json
.gitignore
.eslintrc
.prettierrc
.env (gitignored)
config.json (gitignored)

Imo, this:
Looks better. Has a better 'hierarchy' of files. Is 10 times easier to navigate.
Maybe not a feature, but someone needs to make an extension! :D

Please add manual file re-ordering feature to VSCode. This is the main reason I am considering moving away from VSCode. It is extremely annoying to have files in the wrong order and not be able to reorganize them. If I'm creating a website and I want NavBar component on top since it is the first component of the website, then its not possible. Makes working in VSCode frustrating.

See #119207, which is closed in favour of #27286


Clicking on dual marker time in Waveform widget should move both dual markers

UI version
1.0.48
Your idea
When you click the top bar between dual markers that displays the duration, nothing happens today:

When you left-click, it should move both markers. This should be the same as CTRL left-clicking on one of the markers.
When you right-click, it should display the context menu for the dual markers.
In the case of overlapping dual marker regions, the most recently used one should be selected, just like the markers are resolved.

Added in 1.0.58.


Cannot open stddef.h (dependency of stdlib.h

VSCode Version: 1.17
OS Version: Ubuntu 16.04

Steps to Reproduce:

Write simple c program.
#include <stdlib.h>

Reproduces without extensions: No
When I include stdlib.h, it gets a green squiggly saying that it can not load one of it's dependencies and to edit the include path. When I do that, that squiggly line goes away, but then I get error messages on some of my variables that are from other header files. None of this effects the way the program runs. Everything compiles and runs just fine.

This should be an issue for https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools (I guess you are using it).
@bobbrow do you mind if I move the issue over?

Oh yeah, absolutely! Sorry about that.

@namarino41 It's ok. Do you mind just making a new issue here: https://github.com/Microsoft/vscode-cpptools/issues/new?
I'll close this one since there is nothing we can do from VS Code side.

@namarino41, please open an issue in the extension repo linked above.  It is related to your c_cpp_properties.json file, so if you can share it with us, we will help you resolve the problem.

@bobbrow Opened an issue in the extension repo. Thanks for the help. It's #1202


WIP: Token fixes

WARNING
Please do not merge it (WIP)
Description
support Token feature using the parity extension or geth.
Done

[x]  token: get abi from Contract DB.

use async.waterfall()
check decimals() is available

[x] added a missing transferTokens directive, already used by the DaoController.

[x] web3relay: setup fromBlock param

show contract creation info. (FIXME) : temporal fix. FIXED (8/3)
remove hardecoded fromBlock
parse req.body.fromBlock for future use

[x] token: show decimals

[x] check tx_trace for ERC20 tokenContracts

[x] check ERC20 token validity (6/14)

[x] fixed 'to' address for a contract. show txn.amount for a tokenContract.

[x] enable parity extension locally. (web3.trace.*) (6/28)

[x] save contract creation time both parity/geth (tools/sync.js) (7/22)

[x] reduced transaction db size. (7/22)
- [ ] restrict fromBlock position in the config.json

[x] check decimals() method optionally, (symbol, decimals are not part of ERC20/ERC233)

[x] web3.trace.* does not support pagination. minimal support web3.trace.* pagination.

[x] configurable tokens.json. remove ETC specific tokens from menu

[x] show transfer transactions of all known tokens (8/3)

[x] always decode transfer call transactions (8/3)

[x] show created contract address (8/3)

[x] minimal token support using geth (9/5)

Todo

[ ] fix possible bugs.

Screenshot
etc-explorer + parity (using web3.trace.*)
token transfer

contract transactions

contract source now working

transaction view

We need geth support primarily

without parity too much things to do. anyway I have a plan to support normal geth as well, already done but partially by the etherzero project.

[x] save contract creation time both parity/geth (tools/sync.js)
[x] reduced transaction db size.

Screen shots

correct receiver (decoded) address, decoded amount of tokens

always decode transfer transactions, transaction pagination.

simplified menu (remove ETC specific tokens, extact "tokens.json" as a configurable option)

enable verify contract menu

before

after

almost done 😃
minimal change has been applied using parity extension trace.filter

check speed issue.
fix any possible bugs.

Looks good to me, however we should hide "Known ERC20 token transactions" menu when there is no transaction for account.

Yup, there is an error viewing contract source
ubuntu@ip-172-31-22-53:~/eosc-explorer$ node app.js
CONFIG FOUND: Node:localhost | Port:8282
Web3 connection established
(node:11908) DeprecationWarning: `open()` is deprecated in mongoose >= 4.11.0, use `openUri()` instead, or set the `useMongoClient` option if using `connect()` or `createConnection()`.

TypeError: Cannot read property 'filter' of undefined
    at /home/ubuntu/eosc-explorer/routes/web3relay.js:352:18
    at /home/ubuntu/eosc-explorer/node_modules/async/dist/async.js:473:16
    at next (/home/ubuntu/eosc-explorer/node_modules/async/dist/async.js:5315:29)
    at /home/ubuntu/eosc-explorer/node_modules/async/dist/async.js:958:16
    at /home/ubuntu/eosc-explorer/routes/web3relay.js:318:11
    at nextTask (/home/ubuntu/eosc-explorer/node_modules/async/dist/async.js:5310:14)
    at next (/home/ubuntu/eosc-explorer/node_modules/async/dist/async.js:5317:9)
    at /home/ubuntu/eosc-explorer/node_modules/async/dist/async.js:958:16
    at /home/ubuntu/eosc-explorer/routes/web3relay.js:301:13
    at nextTask (/home/ubuntu/eosc-explorer/node_modules/async/dist/async.js:5310:14)
    at next (/home/ubuntu/eosc-explorer/node_modules/async/dist/async.js:5317:9)
    at /home/ubuntu/eosc-explorer/node_modules/async/dist/async.js:958:16
    at /home/ubuntu/eosc-explorer/routes/web3relay.js:274:11
    at /home/ubuntu/eosc-explorer/node_modules/mongoose/lib/query.js:3118:18
    at newTickHandler (/home/ubuntu/eosc-explorer/node_modules/mpromise/lib/promise.js:234:18)

Explorer crashes during contract source verification

screenshot
make consistent pagination

minimal geth support added. (multi-geth or ethereum-geth)

@pyskell
currently, we are going to prepare ETC node, to test real situation, find any possible bugs
Please feel free to feedback any suggestion :)

etc-explorer on the ETC chain :)

Rebase your PR!

Still on WIP?

Still on WIP?

this is outdated (web3 1.x based).
some parts had been already merged by another PR and some parts remained experimental.


uninstall dfps

hello sir i want to uninstall the effect of this module but idn how even after I removed from magisk it's still working 🤣 please help my phone is mi 11 ultra I'm using official cn rom miui 13.0.13 tag me or text me dm let me know how to stop it i want my old normal refresh rate back 😞

You can't, once it's installed, you're fucked.
It is impossible to uninstall without clean flashing the system


BinaryColor -> u8 conversion

One for @rfuest:
The PR at jamwaffles/sh1106#9 raised a question which I can't remember if we discussed: should impl From<BinaryColor> for u8 exist? It would be be a simple sugar that gets rid of the match in the linked PR and replaces it with a simple pixel.1.into().

I don't think it should. My rewrite of the image module contains a generic way of converting raw data into colors and back, which would get rid of the match. The code is almost ready for review, but depends on #148 being merged before.


feat: implement programmatically toggle text

the text widget can also expand and collapse programmatically e.g if you want to expand/collapse on button click.
closes card [card-11]

 Implement feature to toggle text programmatically


Edit LONGPOWER contract address

@e-asia Looks like the code has been manually merged in?
https://github.com/bonustrack/snapshot-spaces/blob/master/spaces/long/index.json


libsndfile: Add patch for CVE-2018-13139

Motivation for this change
Add patch for CVE-2018-13139 (ref #47121) by applying the upstream patch.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

cc @lovek323 as package maintainer

@GrahamcOfBorg eval

Success on aarch64-linux (full log)
Attempted: libsndfile
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/nknsmpc96w4xjyplia5gssicfw5c9rn3-libsndfile-1.0.28-man
gzipping man pages under /nix/store/nknsmpc96w4xjyplia5gssicfw5c9rn3-libsndfile-1.0.28-man/share/man/
strip is /nix/store/y4ymnvgxygpq05h03kyzbj572zmh6zla-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/nknsmpc96w4xjyplia5gssicfw5c9rn3-libsndfile-1.0.28-man
checking for references to /build in /nix/store/nknsmpc96w4xjyplia5gssicfw5c9rn3-libsndfile-1.0.28-man...
shrinking RPATHs of ELF executables and libraries in /nix/store/2xh5jn80yzyhgrc3rxlxr0kdra9pg7zi-libsndfile-1.0.28-doc
strip is /nix/store/y4ymnvgxygpq05h03kyzbj572zmh6zla-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/2xh5jn80yzyhgrc3rxlxr0kdra9pg7zi-libsndfile-1.0.28-doc
checking for references to /build in /nix/store/2xh5jn80yzyhgrc3rxlxr0kdra9pg7zi-libsndfile-1.0.28-doc...
/nix/store/nqn36mgadwvjimhbp6gcg2wvcy7mriwm-libsndfile-1.0.28-bin

picked to staging (because it's a mass rebuild) in fcde178ed5f76626d57b3b02848f2fedf5fd9928

backported to staging-18.09 in ad9e8ea664782dc04dfaf768127d4bf0164d49df

@xeji - Thanks! And thanks for the cherry-pick, too; didn't realize this was going to be a mass rebuild.

That's what the bot is for!
I also picked this to 18.03;  I'm not sure why it didn't appear in the roundup.


Fasd db should only be updated when finding files interactively

Otherwise we end up with a bunch of ~/.emacs.d/straight/build entries with high weights.
The problem is temporarily avoided on develop by disabling fasd db updates entirely from within Emacs.

FYI, you can fix the pollution in your own Fasd database by just deleting some entries from ~/.fasd manually (or with visual-regexp).

Irrelevant since 5bbeb731f3b8bb4077d38f610d9c0778b21a2bf8.


pill: Fix broken width of input-pill.

This PR fixes a UI bug which was caused by removing the width of pill-container.
GIFs or Screenshots:
Before -

After -

Changes are not visible in the day mode because of the white background.

LGTM

Yeah, flex-grow is a better option, made the changes.

Merged, thanks folks!


Custom input gives an error

Description
I created a custom element, that extends input.
Polymer({

	is: 'week-date-picker-input',

	extends: 'input',

	properties: {

		/**
		* Use this property instead of `value` for two-way data binding.
		*/

		bindValue: {
			observer: '_bindValueChanged',
			type: String
		}
	},

    listeners: {
      'input': '_onInput'
    },

	ready: function() {
		this.bindValue = this.value;
    },

    _bindValueChanged: function() {
      if (this.value !== this.bindValue) {
        this.value = !(this.bindValue || this.bindValue === 0 || this.bindValue === false) ? '' : this.bindValue;
      }
      // manually notify because we don't want to notify until after setting value
      this.fire('bind-value-changed', {value: this.bindValue});
    },

    _onInput: function() {
      this.bindValue = this.value;
    },

    created: function() {
	    this.style.border = '1px solid red';
	},

});

I used it like this inside a vaadin-date-picker-light:
<vaadin-date-picker-light>
  <input is="week-date-picker-input">
</vaadin-date-picker-light>

Expected outcome
It should work similarly the iron-input element.
Actual outcome
As the input is focused, I've this js error in cosole:
vaadin-date-picker-behavior.html:570 Uncaught TypeError: Cannot read property 'focus' of null
    at HTMLElement._focus (vaadin-date-picker-behavior.html:570)

Browsers Affected

[X] Chrome
[X] Firefox
[X] Safari

Hi!
Seems we're lacking some important details about this in our documentation. This is the selector we're currently using to look for the custom input: input[is="iron-input"],paper-input,.paper-input-input,.input – so in your case, adding an class="input" should do the trick!

Yes!
It makes the job.
Thanks a lot.


AUTHORS.md, HISTORY.md and LICENSE installed outside the packages

We have been facing an issue while downgrading packages within our Docker images related to AUTHORS.md not being found.
The problem is that the following pyproject configuration adds those files to the wheel distribution but outside the package itself.
If you download the wheel and take a look, they are outside of minos.
Another way to see the problem is by running pip -V and moving to the installation directory. The files are there among each other package.
Since the LICENSE already gets imported within the wheel distribution info and the other packages aren't actually important for distribution, I propose to delete that pyproject configuration.

This issue is closely related to https://github.com/python-poetry/poetry/issues/2015

I'll fix this issue following a similar approach to https://github.com/pavdmyt/yaspin/pull/135

Hello, I arrived here from the linked poetry issue as I am having a similar issue to the one you resolved.
Did you fix using the magical sdist work to your satisfaction?
I noticed that when I installed minos-microservice-cqrs there is no HISTORY.md file included at all,
The source distribution looks like this:
tar -ztf ~/Downloads/minos-microservice-cqrs-0.7.0.tar.gz
minos-microservice-cqrs-0.7.0/AUTHORS.md
minos-microservice-cqrs-0.7.0/HISTORY.md
minos-microservice-cqrs-0.7.0/LICENSE
minos-microservice-cqrs-0.7.0/README.md
minos-microservice-cqrs-0.7.0/minos/cqrs/init.py
minos-microservice-cqrs-0.7.0/minos/cqrs/exceptions.py
minos-microservice-cqrs-0.7.0/minos/cqrs/handlers.py
minos-microservice-cqrs-0.7.0/minos/cqrs/services.py
minos-microservice-cqrs-0.7.0/pyproject.toml
minos-microservice-cqrs-0.7.0/setup.py
minos-microservice-cqrs-0.7.0/PKG-INFO
with the files at the top level
the wheel omits these altogether:
tar -ztf ~/Downloads/minos_microservice_cqrs-0.7.0-py3-none-any.whl
minos/cqrs/init.py
minos/cqrs/exceptions.py
minos/cqrs/handlers.py
minos/cqrs/services.py
minos_microservice_cqrs-0.7.0.dist-info/LICENSE
minos_microservice_cqrs-0.7.0.dist-info/WHEEL
minos_microservice_cqrs-0.7.0.dist-info/METADATA
minos_microservice_cqrs-0.7.0.dist-info/RECORD
is this what you intended?

Right! That's what we meant to do.
All of our Minos packages (cqrs, common, networks...) have those files. We don't mind to put them within the sdist because we never install from it. The problem comes just when putting them within the wheel, since if more than one of Minos packages get installed using pip, there is a conflicting overriding of those files at the root level.
Does this solve your issue? Don't hesitate to ask further!


To do list app using oops concepts java

To do list app using oops #4344

Close #4344

Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md

@pranjay-poddar @MohitGupta121

@MohitGupta121 @pranjay-poddar please review this pr

@TusharKesarwani


update Peercoin logo to it's 2018 revision

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

[x] Filename in the lowercase format
[x] Image format: png
[x] Image size: 256 by 256 px

Thank you for an update. Next step will be to integrate Peercoin in https://github.com/TrustWallet/wallet-core


JavaScript

Javascript
User Story
As a boot camp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
Acceptance Criteria
Given a Prework Study Guide website
WHEN I view the study guide
THEN I  can see the four topics I learned listed along with a suggestions on what I should study first

I also faced a similar issue on my site but thankfully I hire a developer which resolve that's issue.


feat: add type comment to exported plugin

Fixes #487.
This will give a bit nicer of an IDE experience for folks working in editors such as VS Code that have built-in TypeScript support.

Shouldn't help as TS doesn't read JSDoc comments from node_modules?
Would need to compile it to a .d.ts?

parserOptions.projectService picks it up, it happens in the repro linked in the issue.

Even when maxNodeModuleJsDepth hasn’t been set to something other than the default 0?
Such behavior has already caused issues in ESLint as TS has an undocumented behavior of setting it when using jsconfig.json: https://github.com/eslint/eslint/issues/18100#issuecomment-1971500684
JSDoc comments should not be relied upon

Even when maxNodeModuleJsDepth hasn’t been set to something other than the default 0?

Yes, per the reproduction case I linked in the issue.
Agreed that .d.ts files would be better. That's more work that I don't have time for right now.
Personally, I'd rather lean towards "perfect is the enemy of good" and ship this now + hope for that eventually. There's no harm in including these type-rich JSDocs for pure .js codebases. They benefit the codebase's development itself, help pave the path for more formal TS adoption, and can also help in cases like the reproduction I linked in the issue.

Even when maxNodeModuleJsDepth hasn’t been set to something other than the default 0?

Yes, per the reproduction case I linked in the issue

So typescript eslint is not respecting the tsconfig in this regard?
I’m pro fixing #310 but against making any changes to JSDoc comments because others have decided to consume them as published types. https://github.com/eslint/eslint/issues/18100#issuecomment-1971500684 is one of many proofs that it’s a bad idea to consume JSDoc comments from third party modules
Unless this module publishes type definitions this module should be interpreted as untyped is my opinion

@voxpelli it's also useful for internal development and doesn't impact users using sanctioned type methods. If we ignore the reasoning around external types, do you have any remaining blockers?

@JoshuaKGoldberg no other blockers, if we change it so that this doesn't promote usage of it externally in any way then I'm okay with it

The comment as-is is exactly what one would do for a purely internal change. There's nothing to be done to promote or not-promote it externally.

Removing the Fixes 😜

Thanks all!


Fix Scroll issue in Shifting and Resource

Proposed Changes

Fixes #7487
Used Shadcn's Scroll Area for scrolling

@ohcnetwork/care-fe-code-reviewers
https://github.com/user-attachments/assets/4b2a9ff5-6053-4d8a-bef0-ad696e8d62d5
Merge Checklist

[ ] Add specs that demonstrate bug / test a new feature.
[ ] Update product documentation.
[ ] Ensure that UI text is kept in I18n files.
[ ] Prep screenshot or demo video for changelog entry, and attach it to issue.
[ ] Request for Peer Reviews
[ ] Completion of QA

Summary by CodeRabbit

New Features

Introduced a ScrollArea component for improved scrolling experience in the Kanban sections.
Adjusted the visible area for items to enhance usability.

Bug Fixes

Updated scrolling behavior to allow horizontal scrolling while hiding vertical overflow.

Duplicate of #9268. This is the 3rd PR for the same issue. I'd suggest trying to salvage either the #9268 or #9475.
If you are encountering errors, work to debug those errors rather than opening a new PR 👍

Hey @Jeffrin2005, it’s not fetching beyond the default limit on scroll anymore, which it was doing previously.

@AdityaJ2305 Bro can you explain more detail ?

Yep, I'll share video with you here

Video Link
Hi @Jeffrin2005, have a look at this video. In the completed section on the right side, the next set of cards used to load on scroll previously. However, in the deployment of your PR, this functionality is missing.


Japanese characters in program directory causes UnicodeDecodeError

Prerequisites

[x] Did you read FAQ section?
[x] Did you test with the latest releases or commit ?

Description
On Windows 10 x64, latest version (pixivutil20181008)
Just as the title states. I first tried running it from my downloads folder, and got this error:

UnicodeDecodeError: 'utf8' codec can't decode byte 0x83 in position 9: invalid start byte

I attempted to reproduce it with japanese folders at root directory, and successfully did. This is the full log of a test:

PixivDownloader2 version 20181008
https://github.com/Nandaka/PixivUtil2/releases
Donate at https://bit.ly/PixivUtilDonation
Reading C:\テスト\config.ini ...
done.
Traceback (most recent call last):
File "PixivUtil2.py", line 2258, in
File "PixivUtil2.py", line 2120, in main
File "PixivHelper.pyc", line 323, in toUnicode
UnicodeDecodeError: 'utf8' codec can't decode byte 0x83 in position 3: invalid start byte

The byte it can't decode is position 3, exactly where the Japanese character appears in the directory.
I've avoided this by moving the program into my dedicated portable programs folder, but it's still an issue nonetheless, and wanted to let you know.
Off-topic, but thank you very much for your work! I've used your program since 2015, but haven't been using Pixiv recently. I've gotten back into using it again, and came here to be pleasantly suprised that you still actively update it. Amazing work!

I've successfully solved the issue. I actually already had Japanese locale set on my PC, but I had to check the "Use Unicode UTF-8" in order to get it to work. I've had some issues with other programs too, so hopefully this will fix that too. Thanks for the help!


Support not only languages with basic Latin characters

You have a regular expression in your code:
const correctTitle = title.replace(/[^\s-]\w+/g, (word, index) => {

The problem is that the plugin doesn't work with languages with extended Latin (such as the special letters of the German alphabet) and Cyrillic. It is worth adding their support.

The plugin was developed following capitalization rules for titles written in English. I'm not sure if these rules apply to other languages. Adding the ability to increase the number of lowercase words is a good idea, but this plugin is mainly for linting English titles.

Added, thank for the feedback!


Issues using pattern matching to proxy to multiple hosts.

I'm trying to utilize the pattern matching to use different proxies.
app.use(['/api/**', '!/api/test/**'], { target: 'http://localhost:8000' }); // ASP.NET
app.use('/api/test/**', { target: 'http://localhost:9000' }); // json-server

This configuration is always routing to http://localhost:8000.  Ideally, every request except /api/test/** should go to http://localhost:8000.  And /api/test/** would go to http://localhost:9000.
It seems that express is only utilizing the first match, then ignoring the other one.

I just realized why my matchers weren't working.  I should have specified the /api/test/** route first, like this...
app.use('/api/test/**', { target: 'http://localhost:9000' }); // json-server
app.use(['/api/**', '!/api/test/**'], { target: 'http://localhost:8000' }); // ASP.NET

This made it work.


clear console.debug in repo

just noting: sometimes I see HTML output in the console
not sure where its coming from


doc: change plank.yaml to plank_.yaml

The board file used by twister is the normalized board target and not just the board name.
Indicate this by changing plank.yaml to plank_.yaml in the board porting guide.

@tejlmand should you own this documentation file so that in the future assignee gets properly set?

@tejlmand coming back to this?

@tejlmand coming back to this?

fixes appliead and rebased.


Customer Guide for Aurora Multi AZ. Resolves #580

@ahus1 @vramik @martin-kanis Let me know what you think. I've focused mainly on content, so I'm sure there's many ways we can make this prettier ... my adoc skills are limited, so all tips welcome!
I have split creating an Aurora DB and the peering connections into two distinct guides, as the latter is applicable to other Aurora deployment types and the process must be repeated for every ROSA cluster that requires a DB connection.
Closes #580

Thank you for this documentation, this is very detailed. Some thoughts:

There are now two guides, one for the DB and one for the peering. If we expect users to perform always both steps, so IMHO those should be combined into one guide. If we want to have different building blocks later for example for a Aurora global database which would involve different steps, then we should keep it as is.
The guide is very hands-on and descriptive, as it captures the outputs. An alternative would be be a less descriptive include of parts of our shell script for the Aurora setup, which would give us less duplication. As the Aurora setup is quite stable, I suppose we continue as you outlined it here - I just want to make sure we have discussed it.
At the end of setting up the peering connection, there is the - all to obvious step - to add the JDBC URL plus credentials into the Keycloak CR to connect to the database. Even if it is obvious to us, it would be IMHO good to mention where to place it.

There are now two guides, one for the DB and one for the peering. If we expect users to perform always both steps, so IMHO those should be combined into one guide. If we want to have different building blocks later for example for a Aurora global database which would involve different steps, then we should keep it as is.

Ack. I'll try to re-work the peering connection to be a reusable procedural block that can be nested in multiple guides.

The guide is very hands-on and descriptive, as it captures the outputs. An alternative would be be a less descriptive include of parts of our shell script for the Aurora setup, which would give us less duplication. As the Aurora setup is quite stable, I suppose we continue as you outlined it here - I just want to make sure we have discussed it.

I don't think including parts of our Aurora setup scripts would be very understandable for users, as we heavily modify the outputs of many of the commands in order to capture values in variables etc and use 3rd party tools such as jq.

At the end of setting up the peering connection, there is the - all to obvious step - to add the JDBC URL plus credentials into the Keycloak CR to connect to the database. Even if it is obvious to us, it would be IMHO good to mention where to place it.

Do you think stating the need for this in the "Next Steps" section and linking the relevant guide is sufficient, or do you envisage us explicitly documenting these steps in the same guide? IMO the latter is overkill if we want the documentation to be more modular (maybe that's not the case?).

I have added a new commit which combines the two guides using partials, so we can re-use the peering connection procedure in future guides if required.
I have also replaced the "Next Steps" section with a "Keycloak Deployment" section. This isn't exhaustive instructions, but it explains the changes required to the Keycloak CR when deploying with Aurora vs Postgres.

Do you think stating the need for this in the "Next Steps" section and linking the relevant guide is sufficient

I was thinking to have 1-3 sentences in the form of: "Note the username and password and a JDBC URL to deploy Keycloak as described in the XXX guide". The thing that triggered it for me was me seeing the URL used for the PostgreSQL client is different than the JDBC URL used for Keycloak.

My comment overlapped with your latest commit. That latest change works well - thank you.

@martin-kanis - for a local preview of the docs, use the script author.sh for an authors preview. The build script will clone the main repo main branch to render the contents (possibly from multiple branches).

@martin-kanis - for a local preview of the docs, use the script author.sh for an authors preview. The build script will clone the main repo main branch to render the contents (possibly from multiple branches).

Thank you for the advice. @ryanemerson I can know see rendered pages. Only thing missing, is the reference in doc/kubernetes/modules/ROOT/nav.adoc to see links in the left navigation menu.


ESLint: no-useless-call

https://github.com/eslint/eslint/commit/2f2924f5fb8cefe403279ea4e0bdf5a6d6b4ed55

This is great,  for ES6.
In ES5 it would limit the user from using apply.

@dcousens it doens't prevent use of appply altogether. Only when it is better to use the () call syntax.
Do you see something that I do not?

@mightyiam Nice - this rule looks good to me, unless I'm missing something that @dcousens has caught. The new rule is in the master branch, so we have to wait for a release before we can add this rule.

Nevermind,  I was mistaking the changes for prefer-spread to be relevant to this rule also.
:+1: lets put it in.

This will be fixed in eslint 1.0.0 and standard 5.0.0. https://github.com/feross/standard/issues/192


Growth Chamber MK2 makes alot of stuff without regard to a server economy while being incredibly cheap.

Description (Required)

The Growth Chamber MK2 is a giant upgrade for little. 4x the speed and produce.
This can be ridiculous for servers to handle.  Overall I think this block needs to be nerfed.
Maybe adding a config option might work as well.
Steps to reproduce the Issue (Required)

Put one carrot into the Growth Chamber MK2, get 12 out
???
Profit.
Expected behavior (Required)

The growth chambers growth rate being much less since how inexpensive it is.
Server Log / Error Report

Not applicable
Environment (Required)

Not applicable

Fix: https://github.com/ProfElements/DynaTech/pull/37

Fixed in 356dc14


create a virtual machine file: docker or vagrant

for easy installation of VoSeq.

fixed. We are using Vagrant.


Middleware support

Hello,
Just a question, is middleware supported?

No but could you create PR that extends router with tests. I will merge it.


"Here" package caching does not work

Relates to #58 (maybe)
I have a medium sized angular application (13MB) that was taking way longer than it used to when it was a small project. I started digging through the code and there are many many repeated go list calls made with the same arguments and producing the same output.
Looks like these functions are ignoring the cache and running the go commands every time (slowing down execution times significantly)
https://github.com/gobuffalo/here/blob/master/pkg.go#L17
https://github.com/gobuffalo/here/blob/master/dir.go#L11
https://github.com/gobuffalo/here/blob/master/dir.go#L65
The way the gobuffalo/here module is used seems to create a new here doc everytime a call is made to the module, thus creating a new cache.
One of the public methods used by the pkger code a lot (about 10 times over 9 files):
https://github.com/gobuffalo/here/blob/master/dir.go#L61
gobuffalo/here New() method (creates a new cache)
https://github.com/gobuffalo/here/blob/master/here.go#L21
I'm not sure if this is an issue with gobuffalo or the integration of it within this project, but from looking over the code it seems the caching is local to each here object and there is a here object for each file - so the cache is per-file (i.e always empty). Implementing a very hacky static cache increased the performance significantly.
Although I could be totally off base on this, as I can't spend all afternoon digging into it. However, as amazing as this project is, it seems unfit for any projects with more than a handful of files / folders right now.

I have made a couple changes to the code and got the time to build down significantly by increasing the cache hits. It appears the caching is working mostly as intended now, but I am still curious as to why there are so many calls to go list -json and go list json -m during the walk step? I think thats a much larger fix though.
Going to make a PR shortly for my changes for discussion.


feat: add gateway in front of the bridge ui to solve browser referencing issues

https://polygon.atlassian.net/browse/DVT-1450

Closing in favor of #63


The sample app has a forgot password link in the Login page, but there is no ForgotPassword page

See the line of code at https://github.com/aws/aws-aspnet-cognito-identity-provider/blob/e54f03d7854e17b05434ed34a3c67fa992ffe45c/samples/Samples/Areas/Identity/Pages/Account/Login.cshtml#L39
There is no ForgotPassword page, so it just results in a page reload.
Is it possible to advice how to handle forgot passwords?

Hi @alexisatkinson,
Good afternoon.
Thanks for posting the guidance question. Please refer the following links to get some idea on how to implement Forgot Password functionality:

IAmazonCognitoIdentityProvider.ForgotPassword(ForgotPasswordRequest)

REST API Reference for ForgotPassword Operation

[Stackoverflow post][https://stackoverflow.com/questions/58729214/how-to-use-forgot-password-custom-template-on-net-using-aws-cognito) which can be used as a general reference (not permanent solution).

Please let me know if this helps and if we could close this issue.
Thanks,
Ashish

Sample app https://github.com/aws/aws-aspnet-cognito-identity-provider/tree/master/samples has been updated with Forgot Password scenario as part of commit https://github.com/aws/aws-aspnet-cognito-identity-provider/commit/9d8aa1faa018707df06c79efd75947ea9938adba#diff-24baa7a731ce04b431af93d94cba8e0160a0e6a4607edc2d70c595dd098e56cf.


chore(main): release 2.6.17

:robot: I have created a release beep boop
2.6.17 (2024-10-07)
Bug Fixes

deps: update rust crate axum to v0.7.7 (ab45cf8)
deps: update rust crate charts-rs to v0.3.18 (58dd7bc)
deps: update rust crate clap to v4.5.19 (a3eacb4)
deps: update rust crate declare_schema to 0.0.5 (7b767e4)
deps: update rust crate futures to v0.3.31 (e961c99)
deps: update rust crate once_cell to v1.20.1 (c45fabe)
deps: update rust crate once_cell to v1.20.2 (3eee4a5)
deps: update rust crate reqwest to v0.12.8 (6a90266)
deps: update rust crate service_conventions to 0.0.22 (bc23fdb)
deps: update rust crate tonic to v0.12.3 (1599001)
deps: update rust crate tower-http to v0.6.1 (337b342)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/philipcristiano/et/releases/tag/v2.6.17 :sunflower:


FIXfix jsonb is not in predict column

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run p0


adopt new kubeadm logo #14741

Change for /en files.

/assign @sftim

/approve

@icheikhrouhou Can you help follow up?


esp_rmaker_core error (MEGH-816)

Hi, I build and flash firmware to an ESP32WROOM, and get this error:
E (824) esp_rmaker_core: Failed to initialise Node Id
E (824) app_main: Could not initialise ESP RainMaker. Aborting!!!
This is Switch example, it build OK and then flash OK too. BOOT and Led output are ok too, it turn ON and OFF the output led. But WiFi dont start .
Thanks!!!
Ale Conti

I tried with this type of problem on an m5stack. I think the support for esp32 card is incomplete ? There are problems with retrieving the node id on esp32 (it's work with esp32s2) and with claiming support ?

We will start giving out support for ESP32 on-demand and later open up to a wider audience. Can you send the email id you used for registering on ESP RainMaker to<EMAIL_ADDRESS>

I tried with this type of problem on an m5stack. I think the support for esp32 card is incomplete ? There are problems with retrieving the node id on esp32 (it's work with esp32s2) and with claiming support ?

Yes, sure, I advanced one more step, and now it creates NODE ID , but fails when claim MQTT Credentials...
I (851) wifi:Init dynamic rx buffer num: 32
I (881) esp_rmaker_core: Node ID ----- 30AEA40CA360
E (881) esp_rmaker_core: Failed to initialise MQTT Config. Credentials missing.
E (881) app_main: Could not initialise ESP RainMaker. Aborting!!!

The code actually generate certificates for esp32s2 but not for esp32. It seem to be in progress :)

Yes, self claiming service is only for esp32s2 now, we must wait for our esp32 ;) ...

Or we can provide some help... This project is great !

Yes of course! In the menuconfig of ESP32s2 the self claim option appears to setup, where the URL and the Host MQTT endpoint are configured to generate the MQTT certificate. Very interesting project, I have a batch of esp32WROOM to apply it, and the application is very interesting as presented. I'm working with AWS free trier for the backend, and AWS amplify with React Native for the App, but this project directly saves me a lot of time and cost.


Expose ATECC608A vault to Elixir

@SanjoDeundiak the goal is to make it possible to replace these functions with Rust equivalents
https://github.com/ockam-network/ockam/blob/develop/implementations/elixir/lib/ockam/channel/xx.ex#L116-L212

There is a possibility that a call like encode_message_2 is too long to be a NIF ... the concurrency strengths of Erlang VM come from being able to easily schedule thousands of concurrent processes. A long running NIF can totally kill that .... so we;ll have to measure once we have the above in place.
If this works, that would be win because then we won't have to maintain an elixir version of the key exchange.

Duplicate of #675


Installation should work on Clinical-db

(prod170926) [hiseq.clinical@hippocampus clinical-db.scilifelab.se]$ bash ~/STAGE/servers/resources/clinical-db.scilifelab.se/update-genotype-stage.sh master
running script as user hiseq.clinical, continue
on the host clinical-db.scilifelab.se, continue
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 0), reused 1 (delta 0), pack-reused 0
Unpacking objects: 100% (5/5), done.
From https://github.com/Clinical-Genomics/genotype
 * branch            master     -> FETCH_HEAD
   3d666e2..3882cda  master     -> origin/master
Updating 905a465..3882cda
Fast-forward
 .bumpversion.cfg | 2 +-
 setup.py         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
Processing /home/hiseq.clinical/STAGE/genotype
Requirement already satisfied, skipping upgrade: click in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (6.7)
Requirement already satisfied, skipping upgrade: PyYAML in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (5.3)
Requirement already satisfied, skipping upgrade: Alchy in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (2.2.2)
Requirement already satisfied, skipping upgrade: SQLAlchemy in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (1.3.13)
Requirement already satisfied, skipping upgrade: cyvcf2<0.10.0 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (0.9.0)
Requirement already satisfied, skipping upgrade: xlrd in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (1.2.0)
Requirement already satisfied, skipping upgrade: pymysql in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (0.9.3)
Requirement already satisfied, skipping upgrade: pysam in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (0.15.2)
Requirement already satisfied, skipping upgrade: Flask in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (1.1.1)
Requirement already satisfied, skipping upgrade: Flask-Bootstrap in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (<IP_ADDRESS>)
Requirement already satisfied, skipping upgrade: Flask-Reverse-Proxy in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (<IP_ADDRESS>)
Requirement already satisfied, skipping upgrade: Flask-SQLAlchemy==2.1 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (2.1)
Requirement already satisfied, skipping upgrade: Flask-Alchy in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (0.5.0)
Requirement already satisfied, skipping upgrade: Flask-Security in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (3.0.0)
Requirement already satisfied, skipping upgrade: werkzeug<1.0.0 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (0.16.1)
Requirement already satisfied, skipping upgrade: Flask-Login in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (0.4.1)
Requirement already satisfied, skipping upgrade: Flask-Dance in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (3.0.0)
Requirement already satisfied, skipping upgrade: ruamel.yaml in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (0.16.7)
Requirement already satisfied, skipping upgrade: six~=1.12 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from genotype==2.3.3) (1.12.0)
Requirement already satisfied, skipping upgrade: pydash>=3.4.7 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Alchy->genotype==2.3.3) (4.7.6)
Requirement already satisfied, skipping upgrade: numpy in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from cyvcf2<0.10.0->genotype==2.3.3) (1.18.1)
Requirement already satisfied, skipping upgrade: itsdangerous>=0.24 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask->genotype==2.3.3) (1.1.0)
Requirement already satisfied, skipping upgrade: Jinja2>=2.10.1 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask->genotype==2.3.3) (2.11.1)
Requirement already satisfied, skipping upgrade: visitor in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-Bootstrap->genotype==2.3.3) (0.1.3)
Requirement already satisfied, skipping upgrade: dominate in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-Bootstrap->genotype==2.3.3) (2.4.0)
Requirement already satisfied, skipping upgrade: Flask-Mail>=0.7.3 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-Security->genotype==2.3.3) (0.9.1)
Requirement already satisfied, skipping upgrade: Flask-Principal>=0.3.3 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-Security->genotype==2.3.3) (0.4.0)
Requirement already satisfied, skipping upgrade: Flask-WTF>=0.13.1 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-Security->genotype==2.3.3) (0.14.2)
Requirement already satisfied, skipping upgrade: passlib>=1.7 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-Security->genotype==2.3.3) (1.7.2)
Requirement already satisfied, skipping upgrade: Flask-BabelEx>=0.9.3 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-Security->genotype==2.3.3) (0.9.3)
Requirement already satisfied, skipping upgrade: oauthlib in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-Dance->genotype==2.3.3) (2.1.0)
Requirement already satisfied, skipping upgrade: requests>=2.0 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-Dance->genotype==2.3.3) (2.22.0)
Requirement already satisfied, skipping upgrade: requests-oauthlib>=1.0.0 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-Dance->genotype==2.3.3) (1.1.0)
Requirement already satisfied, skipping upgrade: urlobject in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-Dance->genotype==2.3.3) (2.4.3)
Requirement already satisfied, skipping upgrade: ruamel.yaml.clib>=0.1.2; platform_python_implementation == "CPython" and python_version < "3.8" in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from ruamel.yaml->genotype==2.3.3) (0.2.0)
Requirement already satisfied, skipping upgrade: MarkupSafe>=0.23 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Jinja2>=2.10.1->Flask->genotype==2.3.3) (1.1.1)
Requirement already satisfied, skipping upgrade: blinker in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-Mail>=0.7.3->Flask-Security->genotype==2.3.3) (1.4)
Requirement already satisfied, skipping upgrade: WTForms in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-WTF>=0.13.1->Flask-Security->genotype==2.3.3) (2.2.1)
Requirement already satisfied, skipping upgrade: Babel>=1.0 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-BabelEx>=0.9.3->Flask-Security->genotype==2.3.3) (2.8.0)
Requirement already satisfied, skipping upgrade: speaklater>=1.2 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Flask-BabelEx>=0.9.3->Flask-Security->genotype==2.3.3) (1.3)
Requirement already satisfied, skipping upgrade: certifi>=2017.4.17 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from requests>=2.0->Flask-Dance->genotype==2.3.3) (2019.11.28)
Requirement already satisfied, skipping upgrade: idna<2.9,>=2.5 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from requests>=2.0->Flask-Dance->genotype==2.3.3) (2.8)
Requirement already satisfied, skipping upgrade: chardet<3.1.0,>=3.0.2 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from requests>=2.0->Flask-Dance->genotype==2.3.3) (3.0.4)
Requirement already satisfied, skipping upgrade: urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from requests>=2.0->Flask-Dance->genotype==2.3.3) (1.25.8)
Requirement already satisfied, skipping upgrade: pytz>=2015.7 in /home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages (from Babel>=1.0->Flask-BabelEx>=0.9.3->Flask-Security->genotype==2.3.3) (2019.3)
Building wheels for collected packages: genotype
  Building wheel for genotype (setup.py) ... done
  Created wheel for genotype: filename=genotype-2.3.3-py2.py3-none-any.whl size=29596 sha256=b48e680919a4931ec877b178b4909f08e41eaa51daf80cb17efbecff56ff6f9e
  Stored in directory: /tmp/pip-ephem-wheel-cache-sf_rys0g/wheels/28/e2/37/f3eabc7a923a7c5db87e6e444d2d9d4e916fca93c7550a18d3
Successfully built genotype
Installing collected packages: genotype
  Found existing installation: genotype 2.3.2
    Uninstalling genotype-2.3.2:
      Successfully uninstalled genotype-2.3.2
Successfully installed genotype-2.3.3
WARNING: You are using pip version 19.3.1; however, version 20.0.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
genotype-stage: stopped
genotype-stage: started
/home/hiseq.clinical/servers/resources/clinical-db.scilifelab.se
repository is dirty
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	../../config/clinical-db.scilifelab.se/scout-stage.conf.py.old
	src/

nothing added to commit but untracked files present (use "git add" to track)
This deletes any changed/untracked files, are you sure? y/[n]y
HEAD is now at f3077c2 Bump version: 3.3.2 → 4.0.0
Logging deploy ...
Getting deployer... done.
Getting last commit message and SHA... done.
Getting version of deploy scripts... /home/hiseq.clinical/servers/resources/clinical-db.scilifelab.se
done.
Log deploy... done.
Running --version on each Clinical-Genomics developed tool to verify that all requirements are met:
networkx 2.3 has requirement decorator>=4.3.0, but you have decorator 4.1.2.
/home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages/sqlalchemy/orm/relationships.py:2059: SAWarning: Cascade settings "delete, merge, save-update" should not be combined with a viewonly=True relationship.   This configuration will raise an error in version 1.4.  Note that in versions prior to 1.4, these cascade settings may still produce a mutating effect even though this relationship is marked as viewonly=True.
  "viewonly=True." % (", ".join(sorted(non_viewonly)))
cg, version 7.11.0
genotype, version 2.3.3
housekeeper, version 2.5.0
trailblazer, version 6.1.0
/home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages/weasyprint/text.py:28: UserWarning: There are known rendering problems with Cairo <= 1.14.0
  warnings.warn('There are known rendering problems with Cairo <= 1.14.0')
/home/hiseq.clinical/miniconda/envs/stage/lib/python3.6/site-packages/weasyprint/fonts.py:43: UserWarning: @font-face support needs Pango >= 1.38
  warnings.warn('@font-face support needs Pango >= 1.38')
scout, version 4.11.1
(prod170926) [hiseq.clinical@hippocampus clinical-db.scilifelab.se]$ bash ~/STAGE/servers/resources/clinical-db.scilifelab.se/update-genotype-prod.sh master
running script as user hiseq.clinical, continue
on the host clinical-db.scilifelab.se, continue
This will install the latest version of genotype on master in production, are you sure? y/[n]y
remote: Enumerating objects: 158, done.
remote: Counting objects: 100% (158/158), done.
remote: Compressing objects: 100% (35/35), done.
remote: Total 293 (delta 133), reused 131 (delta 123), pack-reused 135
Receiving objects: 100% (293/293), 53.16 KiB | 0 bytes/s, done.
Resolving deltas: 100% (192/192), completed with 14 local objects.
From https://github.com/clinical-genomics/genotype
   7599ee7..3882cda  master     -> origin/master
 * [new branch]      CI/add-jobs -> origin/CI/add-jobs
 * [new branch]      new_lib_path -> origin/new_lib_path
 * [new branch]      trending_dev -> origin/trending_dev
 * [new tag]         2.3.3      -> 2.3.3
 * [new tag]         2.3.0      -> 2.3.0
 * [new tag]         2.3.1      -> 2.3.1
 * [new tag]         2.3.2      -> 2.3.2
Removing tests/store/test_store_trending.py
Removing genotype/store/trending.py
Merge made by the 'recursive' strategy.
 .bumpversion.cfg                   |   2 +-
 .github/CODEOWNERS                 |   5 +++++
 .github/PULL_REQUEST_TEMPLATE      |  25 +++++++++++++++++++++++++
 genotype/load/plate.py             |   2 +-
 genotype/server/admin.py           |   4 ++--
 genotype/store/api.py              |  32 ++++++++++++++++++++++++++++++--
 genotype/store/cli.py              |  92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------
 genotype/store/export.py           |  93 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 genotype/store/trending.py         |  61 -------------------------------------------------------------
 requirements.txt                   |   6 ++++--
 setup.py                           |   5 +++--
 tests/store/test_store_export.py   | 166 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/store/test_store_trending.py |  95 -----------------------------------------------------------------------------------------------
 13 files changed, 391 insertions(+), 197 deletions(-)
 create mode 100644 .github/CODEOWNERS
 create mode 100644 .github/PULL_REQUEST_TEMPLATE
 create mode 100644 genotype/store/export.py
 delete mode 100644 genotype/store/trending.py
 create mode 100644 tests/store/test_store_export.py
 delete mode 100644 tests/store/test_store_trending.py
Processing /home/hiseq.clinical/genotype
Collecting click (from genotype==2.3.3)
  Downloading https://files.pythonhosted.org/packages/dd/c0/4d8f43a9b16e289f36478422031b8a63b54b6ac3b1ba605d602f10dd54d6/click-7.1.1-py2.py3-none-any.whl (82kB)
    100% |████████████████████████████████| 92kB 8.7MB/s
Requirement already up-to-date: PyYAML in /home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/site-packages (from genotype==2.3.3)
Requirement already up-to-date: Alchy in /home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/site-packages (from genotype==2.3.3)
Collecting SQLAlchemy (from genotype==2.3.3)
  Downloading https://files.pythonhosted.org/packages/8c/30/4134e726dd5ed13728ff814fa91fc01c447ad8700504653fe99d91fdd34b/SQLAlchemy-1.3.15.tar.gz (6.1MB)
    100% |████████████████████████████████| 6.1MB 174kB/s
Requirement already up-to-date: cyvcf2<0.10.0 in /home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/site-packages (from genotype==2.3.3)
Requirement already up-to-date: xlrd in /home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/site-packages (from genotype==2.3.3)
Requirement already up-to-date: pymysql in /home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/site-packages (from genotype==2.3.3)
Collecting pysam (from genotype==2.3.3)
  Downloading https://files.pythonhosted.org/packages/25/7e/098753acbdac54ace0c6dc1f8a74b54c8028ab73fb027f6a4215487d1fea/pysam-0.15.4.tar.gz (1.6MB)
    100% |████████████████████████████████| 1.6MB 344kB/s
    Complete output from command python setup.py egg_info:
    # pysam: cython is available - using cythonize if necessary
    # pysam: htslib mode is shared
    # pysam: HTSLIB_CONFIGURE_OPTIONS=None
    # pysam: (sysconfig) CC=gcc -pthread
    # pysam: (sysconfig) CFLAGS=-Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
    # pysam: (sysconfig) LDFLAGS=-L/home/hiseq.clinical/miniconda/envs/prod170926/lib -Wl,-rpath=/home/hiseq.clinical/miniconda/envs/prod170926/lib,--no-as-needed
    checking for gcc... gcc -pthread
    checking whether the C compiler works... yes
    checking for C compiler default output file name... a.out
    checking for suffix of executables...
    checking whether we are cross compiling... no
    checking for suffix of object files... o
    checking whether we are using the GNU C compiler... yes
    checking whether gcc -pthread accepts -g... yes
    checking for gcc -pthread option to accept ISO C89... none needed
    checking for ranlib... ranlib
    checking for grep that handles long lines and -e... /bin/grep
    checking for C compiler warning flags... unknown
    checking for special C compiler options needed for large files... no
    checking for _FILE_OFFSET_BITS value needed for large files... no
    checking for _LARGEFILE_SOURCE value needed for large files... no
    checking shared library type for unknown-Linux... plain .so
    checking how to run the C preprocessor... gcc -pthread -E
    checking for egrep... /bin/grep -E
    checking for ANSI C header files... yes
    checking for sys/types.h... yes
    checking for sys/stat.h... yes
    checking for stdlib.h... yes
    checking for string.h... yes
    checking for memory.h... yes
    checking for strings.h... yes
    checking for inttypes.h... yes
    checking for stdint.h... yes
    checking for unistd.h... yes
    checking for stdlib.h... (cached) yes
    checking for unistd.h... (cached) yes
    checking for sys/param.h... yes
    checking for getpagesize... yes
    checking for working mmap... yes
    checking for gmtime_r... yes
    checking for fsync... yes
    checking for drand48... yes
    checking whether fdatasync is declared... yes
    checking for fdatasync... yes
    checking for library containing log... -lm
    checking for zlib.h... yes
    checking for inflate in -lz... yes
    checking for library containing recv... none required
    checking for bzlib.h... no
    checking for BZ2_bzBuffToBuffCompress in -lbz2... no
    configure: error: libbzip2 development files not found

    The CRAM format may use bzip2 compression, which is implemented in HTSlib
    by using compression routines from libbzip2 <http://www.bzip.org/>.

    Building HTSlib requires libbzip2 development files to be installed on the
    build machine; you may need to ensure a package such as libbz2-dev (on Debian
    or Ubuntu Linux) or bzip2-devel (on RPM-based Linux distributions or Cygwin)
    is installed.

    Either configure with --disable-bz2 (which will make some CRAM files
    produced elsewhere unreadable) or resolve this error to build HTSlib.
    checking for gcc... gcc -pthread
    checking whether the C compiler works... yes
    checking for C compiler default output file name... a.out
    checking for suffix of executables...
    checking whether we are cross compiling... no
    checking for suffix of object files... o
    checking whether we are using the GNU C compiler... yes
    checking whether gcc -pthread accepts -g... yes
    checking for gcc -pthread option to accept ISO C89... none needed
    checking for ranlib... ranlib
    checking for grep that handles long lines and -e... /bin/grep
    checking for C compiler warning flags... unknown
    checking for special C compiler options needed for large files... no
    checking for _FILE_OFFSET_BITS value needed for large files... no
    checking for _LARGEFILE_SOURCE value needed for large files... no
    checking shared library type for unknown-Linux... plain .so
    checking how to run the C preprocessor... gcc -pthread -E
    checking for egrep... /bin/grep -E
    checking for ANSI C header files... yes
    checking for sys/types.h... yes
    checking for sys/stat.h... yes
    checking for stdlib.h... yes
    checking for string.h... yes
    checking for memory.h... yes
    checking for strings.h... yes
    checking for inttypes.h... yes
    checking for stdint.h... yes
    checking for unistd.h... yes
    checking for stdlib.h... (cached) yes
    checking for unistd.h... (cached) yes
    checking for sys/param.h... yes
    checking for getpagesize... yes
    checking for working mmap... yes
    checking for gmtime_r... yes
    checking for fsync... yes
    checking for drand48... yes
    checking whether fdatasync is declared... yes
    checking for fdatasync... yes
    checking for library containing log... -lm
    checking for zlib.h... yes
    checking for inflate in -lz... yes
    checking for library containing recv... none required
    checking for bzlib.h... no
    checking for BZ2_bzBuffToBuffCompress in -lbz2... no
    configure: error: libbzip2 development files not found

    The CRAM format may use bzip2 compression, which is implemented in HTSlib
    by using compression routines from libbzip2 <http://www.bzip.org/>.

    Building HTSlib requires libbzip2 development files to be installed on the
    build machine; you may need to ensure a package such as libbz2-dev (on Debian
    or Ubuntu Linux) or bzip2-devel (on RPM-based Linux distributions or Cygwin)
    is installed.

    Either configure with --disable-bz2 (which will make some CRAM files
    produced elsewhere unreadable) or resolve this error to build HTSlib.
    make: ./version.sh: Command not found
    make: ./version.sh: Command not found
    config.mk:2: *** Resolve configure error first.  Stop.
    # pysam: htslib configure options: None
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-ue_161q3/pysam/setup.py", line 241, in <module>
        htslib_make_options = run_make_print_config()
      File "/tmp/pip-build-ue_161q3/pysam/setup.py", line 68, in run_make_print_config
        stdout = subprocess.check_output(["make", "-s", "print-config"])
      File "/home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/subprocess.py", line 336, in check_output
        **kwargs).stdout
      File "/home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/subprocess.py", line 418, in run
        output=stdout, stderr=stderr)
    subprocess.CalledProcessError: Command '['make', '-s', 'print-config']' returned non-zero exit status 2.

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-ue_161q3/pysam/
You are using pip version 9.0.1, however version 20.0.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
(prod170926) [hiseq.clinical@hippocampus clinical-db.scilifelab.se]$ genotype --version
genotype, version 2.2.5
(prod170926) [hiseq.clinical@hippocampus clinical-db.scilifelab.se]$ bash ~/STAGE/servers/resources/clinical-db.scilifelab.se/update-genotype-prod.sh master
running script as user hiseq.clinical, continue
on the host clinical-db.scilifelab.se, continue
This will install the latest version of genotype on master in production, are you sure? y/[n]y
Already up-to-date.
Processing /home/hiseq.clinical/genotype
Collecting click (from genotype==2.3.3)
  Using cached https://files.pythonhosted.org/packages/dd/c0/4d8f43a9b16e289f36478422031b8a63b54b6ac3b1ba605d602f10dd54d6/click-7.1.1-py2.py3-none-any.whl
Requirement already up-to-date: PyYAML in /home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/site-packages (from genotype==2.3.3)
Requirement already up-to-date: Alchy in /home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/site-packages (from genotype==2.3.3)
Collecting SQLAlchemy (from genotype==2.3.3)
  Using cached https://files.pythonhosted.org/packages/8c/30/4134e726dd5ed13728ff814fa91fc01c447ad8700504653fe99d91fdd34b/SQLAlchemy-1.3.15.tar.gz
Requirement already up-to-date: cyvcf2<0.10.0 in /home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/site-packages (from genotype==2.3.3)
Requirement already up-to-date: xlrd in /home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/site-packages (from genotype==2.3.3)
Requirement already up-to-date: pymysql in /home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/site-packages (from genotype==2.3.3)
Collecting pysam (from genotype==2.3.3)
  Using cached https://files.pythonhosted.org/packages/25/7e/098753acbdac54ace0c6dc1f8a74b54c8028ab73fb027f6a4215487d1fea/pysam-0.15.4.tar.gz
    Complete output from command python setup.py egg_info:
    # pysam: cython is available - using cythonize if necessary
    # pysam: htslib mode is shared
    # pysam: HTSLIB_CONFIGURE_OPTIONS=None
    # pysam: (sysconfig) CC=gcc -pthread
    # pysam: (sysconfig) CFLAGS=-Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
    # pysam: (sysconfig) LDFLAGS=-L/home/hiseq.clinical/miniconda/envs/prod170926/lib -Wl,-rpath=/home/hiseq.clinical/miniconda/envs/prod170926/lib,--no-as-needed
    checking for gcc... gcc -pthread
    checking whether the C compiler works... yes
    checking for C compiler default output file name... a.out
    checking for suffix of executables...
    checking whether we are cross compiling... no
    checking for suffix of object files... o
    checking whether we are using the GNU C compiler... yes
    checking whether gcc -pthread accepts -g... yes
    checking for gcc -pthread option to accept ISO C89... none needed
    checking for ranlib... ranlib
    checking for grep that handles long lines and -e... /bin/grep
    checking for C compiler warning flags... unknown
    checking for special C compiler options needed for large files... no
    checking for _FILE_OFFSET_BITS value needed for large files... no
    checking for _LARGEFILE_SOURCE value needed for large files... no
    checking shared library type for unknown-Linux... plain .so
    checking how to run the C preprocessor... gcc -pthread -E
    checking for egrep... /bin/grep -E
    checking for ANSI C header files... yes
    checking for sys/types.h... yes
    checking for sys/stat.h... yes
    checking for stdlib.h... yes
    checking for string.h... yes
    checking for memory.h... yes
    checking for strings.h... yes
    checking for inttypes.h... yes
    checking for stdint.h... yes
    checking for unistd.h... yes
    checking for stdlib.h... (cached) yes
    checking for unistd.h... (cached) yes
    checking for sys/param.h... yes
    checking for getpagesize... yes
    checking for working mmap... yes
    checking for gmtime_r... yes
    checking for fsync... yes
    checking for drand48... yes
    checking whether fdatasync is declared... yes
    checking for fdatasync... yes
    checking for library containing log... -lm
    checking for zlib.h... yes
    checking for inflate in -lz... yes
    checking for library containing recv... none required
    checking for bzlib.h... no
    checking for BZ2_bzBuffToBuffCompress in -lbz2... no
    configure: error: libbzip2 development files not found

    The CRAM format may use bzip2 compression, which is implemented in HTSlib
    by using compression routines from libbzip2 <http://www.bzip.org/>.

    Building HTSlib requires libbzip2 development files to be installed on the
    build machine; you may need to ensure a package such as libbz2-dev (on Debian
    or Ubuntu Linux) or bzip2-devel (on RPM-based Linux distributions or Cygwin)
    is installed.

    Either configure with --disable-bz2 (which will make some CRAM files
    produced elsewhere unreadable) or resolve this error to build HTSlib.
    checking for gcc... gcc -pthread
    checking whether the C compiler works... yes
    checking for C compiler default output file name... a.out
    checking for suffix of executables...
    checking whether we are cross compiling... no
    checking for suffix of object files... o
    checking whether we are using the GNU C compiler... yes
    checking whether gcc -pthread accepts -g... yes
    checking for gcc -pthread option to accept ISO C89... none needed
    checking for ranlib... ranlib
    checking for grep that handles long lines and -e... /bin/grep
    checking for C compiler warning flags... unknown
    checking for special C compiler options needed for large files... no
    checking for _FILE_OFFSET_BITS value needed for large files... no
    checking for _LARGEFILE_SOURCE value needed for large files... no
    checking shared library type for unknown-Linux... plain .so
    checking how to run the C preprocessor... gcc -pthread -E
    checking for egrep... /bin/grep -E
    checking for ANSI C header files... yes
    checking for sys/types.h... yes
    checking for sys/stat.h... yes
    checking for stdlib.h... yes
    checking for string.h... yes
    checking for memory.h... yes
    checking for strings.h... yes
    checking for inttypes.h... yes
    checking for stdint.h... yes
    checking for unistd.h... yes
    checking for stdlib.h... (cached) yes
    checking for unistd.h... (cached) yes
    checking for sys/param.h... yes
    checking for getpagesize... yes
    checking for working mmap... yes
    checking for gmtime_r... yes
    checking for fsync... yes
    checking for drand48... yes
    checking whether fdatasync is declared... yes
    checking for fdatasync... yes
    checking for library containing log... -lm
    checking for zlib.h... yes
    checking for inflate in -lz... yes
    checking for library containing recv... none required
    checking for bzlib.h... no
    checking for BZ2_bzBuffToBuffCompress in -lbz2... no
    configure: error: libbzip2 development files not found

    The CRAM format may use bzip2 compression, which is implemented in HTSlib
    by using compression routines from libbzip2 <http://www.bzip.org/>.

    Building HTSlib requires libbzip2 development files to be installed on the
    build machine; you may need to ensure a package such as libbz2-dev (on Debian
    or Ubuntu Linux) or bzip2-devel (on RPM-based Linux distributions or Cygwin)
    is installed.

    Either configure with --disable-bz2 (which will make some CRAM files
    produced elsewhere unreadable) or resolve this error to build HTSlib.
    make: ./version.sh: Command not found
    make: ./version.sh: Command not found
    config.mk:2: *** Resolve configure error first.  Stop.
    # pysam: htslib configure options: None
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-liqz_hhh/pysam/setup.py", line 241, in <module>
        htslib_make_options = run_make_print_config()
      File "/tmp/pip-build-liqz_hhh/pysam/setup.py", line 68, in run_make_print_config
        stdout = subprocess.check_output(["make", "-s", "print-config"])
      File "/home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/subprocess.py", line 336, in check_output
        **kwargs).stdout
      File "/home/hiseq.clinical/miniconda/envs/prod170926/lib/python3.6/subprocess.py", line 418, in run
        output=stdout, stderr=stderr)
    subprocess.CalledProcessError: Command '['make', '-s', 'print-config']' returned non-zero exit status 2.

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-liqz_hhh/pysam/

@patrikgrenfeldt Done right? I am closing this one. Reopen if you disagree


[SQL] Implement YAML-based file model

Productionalize YAML-based file model implementation from #119

Will work on a pandas UDF generation in the next PR


2 second delay when selecting an item in tmux using Ctrl+T

I am wondering if there is some bad interaction with my tmux config or if this is expected behavior. When I use a bare shell and use the Ctrl+T binding, fzf is insanely fast, and it's perfect. When I am in tmux, it splits and starts working just as fast, but when I select anything, it will take about 2 seconds before the item I selected actually gets entered into the command line.
I think I can workaround it by disabling fzf-tmux but maybe there is something for me to fix here.

I can't reproduce this so I guess I should close it.
I should also mention that this is on OS X (on a system that's been upgraded from Mountain Lion to Mavericks to Yosemite so it's probably got decent cruft buildup).
What I also did was I added TERM=screen-256color to all the fzf calls made in ~/.fzf.zsh. May have had something to do with it, but doubtful on that.

I'm mainly on OSX with tmux but haven't experienced the problem. Anyway thanks for the report.

I have seen it a few more times but it's mostly a rare occurrence. Might be some kind of interaction with tmux. I will be back if I can gain any more insight into this.

I upgraded fzf on OSX (which means my $TERM override got blown away) which brought back the intermittent tmux freezing issue. it always comes back but it might freeze for 4 seconds before the tmux pane becomes responsive again. It isn't tmux itself freezing. It's definitely the longest delay when I use the Alt+C (for fzf-chdir'ing).
Using top/htop/activity monitor didn't lead anywhere, it's not CPU load...
Also this simply does not happen on Linux

I don't think TERM is the reason of the delay. By the way, you have to use screen or screen-256color on tmux. Always, not just for fzf.
Excerpt from: http://tmux.cvs.sourceforge.net/viewvc/tmux/tmux/FAQ
******************************************************************************
* PLEASE NOTE: most display problems are due to incorrect TERM! Before       *
* reporting problems make SURE that TERM settings are correct inside and     *
* outside tmux.                                                              *
*                                                                            *
* Inside tmux TERM must be "screen" or similar (such as "screen-256color").  *
* Don't bother reporting problems where it isn't!                            *
*                                                                            *
* Outside, it must match your terminal: particularly, use "rxvt" for rxvt    *
* and derivatives.                                                           *
******************************************************************************

Okay, I'll deal with that, but yes i dont believe that is related to this issue.
Dug a little more, with pstree:
During fzf Alt+C run:
 | |-+= 79934 lust -zsh
 | | \-+- 90173 lust -zsh
 | |   |--- 90174 lust find -L . ( -path */\.* -o -fstype dev -o -fstype proc ) -prune -o -type d -print
 | |   |--- 90175 lust sed 1d
 | |   |--- 90176 lust cut -b3-
 | |   \--- 90178 lust fzf +m
 | |--= 10149 lust -zsh
 | |-+= 43021 lust -zsh

Seems fine.
After, to see what the hell is running inside the same terminal, which is 79934:
| |-+= 79934 lust -zsh
| | \-+- 90436 lust -zsh
| |   \-+- 90445 lust git symbolic-ref HEAD
| |     \--- 90446 lust /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -license check
| |--= 10149 lust -zsh
| |-+= 43021 lust -zsh

Ok that is pretty screwed up. Something being run by git (which is run by zsh for the RPROMPT prompt on the right side of my zsh shell)


Issues with traefik

Hello, i'am using traefik behind wstunnel but i get a lot of instability

When i'm trying to connect, my domain name is behind cloudfalre but i do not use proxy option. I use just for DNS so it shouldn't cause issues. in traefik i enabled tls passthough for the service.

I'm using wstunnel to passthrough ovpn. and i'm using last version of wstunnel and traefik 3.0

Like that I cannot help you much, as I never used traefik.
Would you mind sharing the log of the client when started in debug ? --log-lvl=debug

Hello, yeah i will. I've also tried without traefik and yeah it work well better instant connection every time + also faster internet access. and also i moved from ovpn to wireguard.


access all healthsites

as a developer I want to access all the healthsites through the API so that i can publish them to the HCID service
for performance reasons we can't return all healthsites at once
we will use pages

https://healthsites.io/api/v1/healthsites/facilities?page=1
until page give empty response


[PALOMABOT] As a user, I want to be able to choose the Aave Yield Chaser Bot on BNB, Gnosis and on Polygon

[PALOMABOT] As a user, I want to be able to choose the Aave Yield Chaser Bot on BNB, Gnosis and on Polygon
Acceptance Criteria

Add Polygon Aave network and stablecoins to the Yield Chaser Bot
Add Gnosis Aave network and stablecoins to the Yield Chaser Bot
Deploy Contracts to BNB, Polygon and Gnosis
Fund the CW contracts for BNB, Polygon and Gnosis

Closing as blocked by the back-end.


Don't lose fields while transferring configs from API to FE

Our "domain objects" were missing some fields. In Layers API there are simply JsonNodes so "everything goes" (whatever was written to the DB). Maybe we should do the same here?

[ ] deploy on dev
[ ] test that the problem is solved

Summary by CodeRabbit

New Features

Enhanced color parameter handling with new sentiment fields ('bad' and 'good').
Added metadata capabilities to style layers with new fields ('id', 'name', 'unit') and improved coefficient precision.
Introduced an 'outliers' field to capture significant deviations in data points.

These updates improve the application's ability to represent and manage emotional and descriptive aspects of styles and colors.

Judging from the Dev deployment, it indeed fixes the bug.


Laggy Label with large amounts of characters

Godot version
4.1stable
System information
Windows 11
Issue description
A common use case for a Label in some applications is to encapsulate it within a ScrollContainer, allowing the user to scroll through the entirety of the text. However, Godot does not permit this use case because the entirety of the text is processed every frame, so a Label with lots of text is unreasonably slow. Further, there does not seem to be a simple workaround to "hack" seamless scrolling into the application.
Any of the label settings or font settings do not noticeably affect the processing of the label. The label is just as slow with word wrap turned off, so it's not a word wrap processing issue. The only factor I could find that affected the time the label spent processing was the amount of text, which sounds like undesirable behavior.
Steps to reproduce

Create a Label
Set the text property to a large amount of text
Check the process time of the application

Minimal reproduction project
The following is a very minimal project consisting of a label with around 100k characters.
laggy_text_mrp.zip

For the general slowness of labels this is a duplicate of:

#77268

The PR doesn't contain any example of the behavior in a ScrollContainer so that part cannot be tested with this, please update your MRP to display that, otherwise this is a duplicate of that

For the general slowness of labels this is a duplicate of:
* [Labels with lots of text very slow in Godot 4 #77268](https://github.com/godotengine/godot/issues/77268)

The PR doesn't contain any example of the behavior in a ScrollContainer so that part cannot be tested with this, please update your MRP to display that, otherwise this is a duplicate of that

I came across this while searching. The above issue has a somewhat misleading title: that issue refers to the label loading being slow, not its processing, and the discussion in the issue is about how to solve the loading problem, with no discussion about the processing. Because of this I decided to report the slow processing as a bug, the use case with the ScrollContainer being just an example.

What do you mean by processing? How is this displayed in the MRP?

What do you mean by processing? How is this displayed in the MRP? The MRP just contains the loading, no processing is done.

Check step 3 in the reproduction steps. In my 12700k system, the profiler reports a process time of around 20ms for the main scene. This means that the frame-by-frame processing of the Label is slow, and not just the initial processing that the above issue is describing. For example, the method given by the author of the above issue does not help reduce the process time.

(The loading issue exists in this MRP, but it's ultimately not the problem I'm reporting.)

Does this persist beyond the initial loading? It looks like it stabilises

Does this persist beyond the initial loading? It looks like it stabilises

Here's an example with the same process as the above image ran for ~8000 frames. It looks like the process time remains very slow throughout.

Can confirm that it is high, though I don't see any spikes at all

It looks like it's somehow physics related, will take a deeper look

This might be a rendering issue. "Process time" includes the time to render the frame.
Please try testing using the compatibility renderer and see if it helps stabalize / reduce frame times

This might be a rendering issue. "Process time" includes the time to render the frame.
Please try testing using the compatibility renderer and see if it helps stabalize / reduce frame times
On my device the frame time drops from 25 ms to 3 ms when switching renderers

Switching to the Compatibility renderer does significantly reduce both the average process time and the variance:

Unfortunately this is still a tad too slow for production, especially given that other use cases for large-text labels (e.g. loading an entire 4 MB book the user can scroll through) would be much larger.
For example, in my current project, FPS tanks to 7 when the player opens one of the books. This could be solved by breaking up the book into pages or chapters; but even just a single chapter tanks the FPS, and I have features that allow the player to interact with the book such as bookmarking or highlighting which would be much less usable in a paginated format.
(After writing the above paragraph, I had an idea and I'm happy to share a workaround)
While Label is laggy, the TextEdit and RichTextLabel nodes are not, and are able to handle millions of characters without issue.
The bug still stands with respect to Labels, but given this workaround it seems that it's not very urgent.

While Label is laggy, the TextEdit and RichTextLabel nodes are not, and are able to handle millions of characters without issue.
The bug still stands with respect to Labels, but given this workaround it seems that it's not very urgent.

@Calinou also reported this behaviour in https://github.com/godotengine/godot/pull/79599

A common use case for a Label in some applications is to encapsulate it within a ScrollContainer, allowing the user to scroll through the entirety of the text.

This is not an intended use case for the Label, it doesn't have a built-in scroll bar for a reason. If you want a lot of text, use RTL.
There are multiple parts to the issue:

What's mentioned in https://github.com/godotengine/godot/pull/79599, setting/changing text is slow since it's all processed as a single entity. This can be changed.
Label sizing code reprocessing it multiple times, again only relevant when changing text and should be already fixed.
Rendering, Label won't know which part of it is visible in the ScrollContainer and render all text. I am not sure if there's a way to fix it.


Don't run migrations in "testing" environment

Hey.
I think it would be wise not to run eyewitness migrations if the environment is "testing" (default Laravel's testing environment) or yet even better, make it configurable to decide on which environments to disable eyewitness.
Alternatively, maybe you can expose an "enabled" config option which we can set to "false" in "phpunit.xml" file.
What do you think?

Hi @kfirba - yeah, great idea.
Leave it with me... I've got some ideas...

Is there any drawback to running those migrations in the local environment? It's just a few extra tables, don't see any harm really.

Not really, you can safely run them on “local” environment. You actually
should run them on “local” environment to ensure you get the result you
expect before deploying.
On Mon, 8 Oct 2018 at 13:00 Arunas Skirius<EMAIL_ADDRESS>wrote:

Is there any drawback to running those migrations in the local
environment? It's just a few extra tables, don't see any harm really.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eyewitness/eye/issues/63#issuecomment-427779662, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIHcFq05bFnepTHw2sMTm2d9iHbPVuE7ks5uiyJDgaJpZM4XLtYM
.


[#2] Finalizes chatbot UI and functionality

[#2]

[x] Improves on previous basic chatbot UI
[x] Implements user request & bot response cycle
[x] Implements text input method for chat
[x] Allows for arbitrary string responses (originating from our other services) in the future


kusk: init at 1.5.4

Description of changes
kusk is the Golang CLI an API gateway implementation for K8S.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

But we're not considering at the moment supporting the Gateway API as the Kusk Gateway project has been sunset.

https://github.com/kubeshop/kusk-gateway/issues/1052#issuecomment-1478052480


Error after setup - Unexpected identifier - Missing stack frames

Getting this error after setup using "npx create-nuxt-app"
Versions:
Nuxt: tried both 2.7.1 & edge(2.8.0)
Npm: 6.4.1
Node: 10.15.3 (Also tried reinstalling...)
No additional modules installed.
Options selected when installing:
Server: None
UI Framework: Bootstrap
Testing framework: None
Nuxt mode: Universal
Added Axios
Any ideas on how to fix this issue?
I tried to look around for similar issues, but none of them seemed related to me.
Sorry if this thread is a duplicate of another one. I just still haven't managed to figure this out yet.

try running 'npm run generate' and then 'npm run dev'

@nderewianka Unfortunately it had no effect.
Interesting thing is that when I build it for production and run it after that, it works,

still having the same problem. do you slve it?

It's the bootstrap-vue that cause the problem.
In nuxt.config.js , under modules remove 'bootstrap-vue/nuxt'.
then create BootstrapVue.js under folder plugins.
`import Vue from 'vue'
import BootstrapVue from 'bootstrap-vue'
Vue.use(BootstrapVue)
`
Back to nuxt.config.js, and register the plugins manually
  plugins: [     'plugins/BootstrapVue'   ],

@noven Thanks a lot! This solution got it working!


Use a contextmanager as part of tests to close connections

Use a contextmanager to make sure we don't hold connections open in our tests: https://docs.python.org/2/library/contextlib.html#contextlib.closing
Places that we can do this:

[x] test_connection.py
[x] test_client.py

This was closed as part of:

8db3498802d4548fac2089f3d031e6a7ea5fca5d
bf6f7fadfe4753cbbbc168e54c600c5e5b66f2e6
fac0dbd8e86cf02b6fbb2512bb81c957490e4ca3


PulsarIOTest.testReadFromSimpleTopic is very flaky

PulsarIOTest uses shared client across all tests [1], which is a race conditions when multiple tests run in parallel.  This manifests as frequent test failures.
[1] https://github.com/apache/beam/blob/master/sdks/java/io/pulsar/src/test/java/org/apache/beam/sdk/io/pulsar/PulsarIOTest.java#L62
Imported from Jira BEAM-14269. Original Jira may contain additional context.
Reported by: SteveNiemitz.

Unable to assign user @MarcoRob. If able, self-assign, otherwise tag @damccorm so that he can assign you. Because of GitHub's spam prevention system, your activity is required to enable assignment in this repo.

Hi @damccorm I am unable to self-assign, can you help me assign this issue to me?
Thanks!

Sure! As of https://github.com/apache/beam/pull/21719 you should be able to self assign with the command .take-issue though, so you should be able to do that going forward! Let me know if you run into any issues with that

@MarcoRob are you working on this?

@pabloem There was a draft PR #17473 seems not having updates for a while.

hm from #17473 it seems more complex, huh? we'll see what I can do...

hm from #17473 it seems more complex, huh? we'll see what I can do...

That seems right. It indicates issues for the IO connector itself.

@MarcoRob are you working on this?

Hi @pabloem
Yes I am working on it, just right now I am working on the migration of Github Actions (GA)
I consulted with Pulsar community and seems like the issue comes from the function that seeks(timestamp) the message from a timestamp it fails sometimes in retrieving the right message with the correct timestamp, so they advice me to use seek(MessageId) instead.  So I am working on changing the function, but right now I paused this while GA I finished the migration.
You can see I got some inputs on that issue in this PR-17473

gotcha. thanks @MarcoRob !

Here another occurrence: https://ci-beam.apache.org/job/beam_PreCommit_Java_Commit/24746/

Still happening: https://ci-beam.apache.org/job/beam_PreCommit_Java_Phrase/5782/consoleFull
14:56:31 > Task :sdks:java:io:pulsar:test
14:56:31
14:56:31 org.apache.beam.sdk.io.pulsar.PulsarIOTest > testReadFromSimpleTopic FAILED
14:56:31     org.apache.beam.sdk.Pipeline$PipelineExecutionException at PulsarIOTest.java:178
14:56:31         Caused by: java.lang.IllegalArgumentException at Preconditions.java:440

@MarcoRob are you no longer working on this?

I'm going to unassign this for now, then. Feel free to comment or grab it again.


docs(Form): fix typo in label

Fixes #2202.

Codecov Report

Merging #2208 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2208   +/-   ##
=======================================
  Coverage   99.73%   99.73%
=======================================
  Files         151      151
  Lines        2622     2622
=======================================
  Hits         2615     2615
  Misses          7        7

Continue to review full report at Codecov.

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

Released in<EMAIL_ADDRESS>