Lanch rerank bge-reranker-large false

Describe the bug
master branch
run：xinference launch -e http://<IP_ADDRESS>:9997 -n bge-reranker-large -t rerank --n-gpu 1 --worker-ip <IP_ADDRESS> --gpu-idx 1 -u bge-reranker-large
then fail：
Launch model name: bge-reranker-large with kwargs: {}
Traceback (most recent call last):
File "/home/gpu/anaconda3/envs/xinference/bin/xinference", line 33, in
sys.exit(load_entry_point('xinference', 'console_scripts', 'xinference')())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/site-packages/click/core.py", line 1157, in call
return self.main(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/site-packages/click/core.py", line 1078, in main
rv = self.invoke(ctx)
^^^^^^^^^^^^^^^^
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/site-packages/click/core.py", line 1688, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/site-packages/click/core.py", line 1434, in invoke
return ctx.invoke(self.callback, **ctx.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/site-packages/click/core.py", line 783, in invoke
return __callback(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/site-packages/click/decorators.py", line 33, in new_func
return f(get_current_context(), *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/aidata/inference/xinference/deploy/cmdline.py", line 765, in model_launch
model_uid = client.launch_model(
^^^^^^^^^^^^^^^^^^^^
File "/aidata/inference/xinference/client/restful/restful_client.py", line 892, in launch_model
raise RuntimeError(
RuntimeError: Failed to launch model, detail: [address=<IP_ADDRESS>:36739, pid=2155786] CUDA call failed lazily at initialization with error: device >= 0 && device < num_gpus INTERNAL ASSERT FAILED at "../aten/src/ATen/cuda/CUDAContext.cpp":50, please report a bug to PyTorch. device=1, num_gpus=
CUDA call was originally invoked at:
File "", line 1, in
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/multiprocessing/forkserver.py", line 274, in main
code = _serve_one(child_r, fds,
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/multiprocessing/forkserver.py", line 313, in _serve_one
code = spawn._main(child_r, parent_sentinel)
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/multiprocessing/spawn.py", line 135, in _main
return self._bootstrap(parent_sentinel)
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/multiprocessing/process.py", line 314, in _bootstrap
self.run()
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/multiprocessing/process.py", line 108, in run
self._target(*self._args, **self._kwargs)
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/site-packages/xoscar/backends/indigen/pool.py", line 258, in _start_sub_pool
logging.config.dictConfig(logging_conf["dict"])
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/logging/config.py", line 823, in dictConfig
dictConfigClass(config).configure()
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/logging/config.py", line 561, in configure
filters[name] = self.configure_filter(filters[name])
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/logging/config.py", line 698, in configure_filter
result = self.configure_custom(config)
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/logging/config.py", line 479, in configure_custom
c = self.resolve(c)
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/logging/config.py", line 396, in resolve
found = self.importer(used)
File "", line 1176, in _find_and_load
File "", line 1147, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/aidata/inference/xinference/init.py", line 38, in
_install()
File "/aidata/inference/xinference/init.py", line 35, in _install
install_model()
File "/aidata/inference/xinference/model/init.py", line 17, in _install
from .llm import _install as llm_install
File "", line 1176, in _find_and_load
File "", line 1147, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/aidata/inference/xinference/model/llm/init.py", line 19, in
from .core import (
File "", line 1176, in _find_and_load
File "", line 1147, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/aidata/inference/xinference/model/llm/core.py", line 23, in
from ...core.utils import parse_replica_model_uid
File "", line 1176, in _find_and_load
File "", line 1126, in _find_and_load_unlocked
File "", line 241, in _call_with_frames_removed
File "", line 1176, in _find_and_load
File "", line 1147, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/aidata/inference/xinference/core/init.py", line 15, in
from .model import ModelActor
File "", line 1176, in _find_and_load
File "", line 1147, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/aidata/inference/xinference/core/model.py", line 47, in
from ..device_utils import empty_cache
File "", line 1176, in _find_and_load
File "", line 1147, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/aidata/inference/xinference/device_utils.py", line 17, in
import torch
File "", line 1176, in _find_and_load
File "", line 1147, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/site-packages/torch/init.py", line 1332, in
_C._initExtension(manager_path())
File "", line 1176, in _find_and_load
File "", line 1147, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/site-packages/torch/cuda/init.py", line 244, in
_lazy_call(_check_capability)
File "/home/gpu/anaconda3/envs/xinference/lib/python3.11/site-packages/torch/cuda/init.py", line 241, in _lazy_call
_queued_calls.append((callable, traceback.format_stack()))
To Reproduce
Cluster model
lanch rerank bge-reranker-large by bash or web page then look worker log
(xinference launch -e http://<IP_ADDRESS>:9997 -n bge-reranker-large -t rerank --n-gpu 1 --worker-ip <IP_ADDRESS> --gpu-idx 1 -u bge-reranker-large)
To help us to reproduce this bug, please provide information below:

Your Python version: 3.11
The version of xinference you use: xinference, version 0.10.2.post1+2.g9602061
Versions of crucial packages.
Full stack of the error.
Minimized code to reproduce the error.

Expected behavior
A clear and concise description of what you expected to happen.
Additional context
Add any other context about the problem here.

@nikhe try v0.10.3 and then close this issue if it works.

@nikhe try v0.10.3 and then close this issue if it works.

Ok I'll try it later


run crash in between

Hi
I was running autohic which crashed in between. I am not sure of the error here. In the log file the final line is
UnpicklingError: invalid load key, '<'.
Thank you
Best regards
Kritika

could you upload all log of run for check

Hi
I have attached all the log files. Please let me know if you need any other information.
Thank you
3d-dna.log
bwa_index.log
epoch_3.log
juicer.log
log.txt
Best regards
Kritika

seem like assign chromosome error, can you upload x.hic ? (if too large can upload google drive)

There are multiple .hic files. I have uploaded them in the following folder in dropbox
https://www.dropbox.com/scl/fo/vthsn6x1jvozt7gjv8c8q/ADA77wYVCyxoHfRqIDqbvow?rlkey=5m799wxrrydhxj800rr9aqne2&st=gqlau7cj&dl=0
Thank you
Best regards
Kritika

I saw your result, I thought your result is fine. but AutoHiC assignment chromosome is difficult (due to the current algorithm problems). I suggest you choose the best of all hic results (recommended to use AutoHiC correction or visual inspection by yourself) and assign the chromosomes manually.

Hello @Jwindler,
I also encounter the similar issue. In the log file, the final line is:
UnpicklingError: invalid load key, '_'
The link contained the log files and the .hic results for your information.
PS: I did not get the epoch_3.log in the logs folder.
https://www.dropbox.com/scl/fo/de1bowkyv33eri211ozva/AHhBRmvTOkOsMSZ69e72JVw?rlkey=hbwkmws34q97nvzdxdzrsb19z&st=z4y129i2&dl=0
Is my result fine?
Thank you.

I checked carefully and there may be no problem with your installation. I think it may be a problem with the file name. I suggest you remove the underscore (_ ) in the genome name and try again.


Dev/version1

I tried to automate the vagrant and virtual box installation by adding a simple script in the scripts folder and triggering it at the start.sh

plz provide a description for your pr following semantic versioning,
link the issue you're trying to solve

Certainly, there is no issue i tried to solve. I've just added a simple
script for some automation as I added in the description
On Wed, 16 Oct 2024 at 13:52, Shayan Ghani @.***> wrote:

plz provide a description for your pr following semantic versioning,
link the issue you're trying to solve
—
Reply to this email directly, view it on GitHub
https://github.com/devopshobbies/boundary-vault-stack/pull/66#issuecomment-2416377607,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AS7FPEMULLSPVXTRDAXF4KLZ3Y46VAVCNFSM6AAAAABQAX6GVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJWGM3TONRQG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

Alright, LGTM but next time start your pr description in the following way:
fix Vagrant and virtualbox installation


Compilation error in OSX and Windows builds when cross-compiling on Linux

Hello,
I've updated bgfx from 509caa6b and i'm seeing this error when cross-compiling using osx-cross (clang 8):
... bgfx/src/renderer_gl.cpp:2068:51: error: use of undeclared identifier 'GL_SRGB_ALPHA_EXT'
                                                        setTextureFormatSrgb(TextureFormat::RGBA8, GL_SRGB_ALPHA_EXT, GL_SRGB_ALPHA_EXT);
                                                                                ^
... bgfx/src/renderer_gl.cpp:2068:70: error: use of undeclared identifier 'GL_SRGB_ALPHA_EXT'
                                                        setTextureFormatSrgb(TextureFormat::RGBA8, GL_SRGB_ALPHA_EXT, GL_SRGB_ALPHA_EXT);
                                                                                ^
... bgfx/src/renderer_gl.cpp:2069:50: error: use of undeclared identifier 'GL_SRGB_EXT'
                                                        setTextureFormatSrgb(TextureFormat::RGB8, GL_SRGB_EXT, GL_SRGB_EXT);
                                                                                ^
... bgfx/src/renderer_gl.cpp:2069:63: error: use of undeclared identifier 'GL_SRGB_EXT'
                                                        setTextureFormatSrgb(TextureFormat::RGB8, GL_SRGB_EXT, GL_SRGB_EXT);

I'm not sure how to fix this.
As far as i can tell, GL_SRGB_ALPHA_EXT is defined in glext.h, but i don't see where it is included in renderer_gl.h. I have BGFX_CONFIG_RENDERER_OPENGL set to 31 and includes conditions should take (and they do) path where gl/glcorearb.h is included. Then, for OSX, there is GL_ARB_shader_objects define and that's all i can see.
Moreover, khronos/gl/glcorearb.h says:

** Do not #include both <GL/glcorearb.h> and either of <GL/gl.h> or
** <GL/glext.h> in the same source file.

If i apply this patch:
--- a/3rdparty/bgfx/src/renderer_gl.h
+++ b/3rdparty/bgfx/src/renderer_gl.h
@@ -55,7 +55,7 @@
 #      if BGFX_CONFIG_RENDERER_OPENGL >= 31
 #              include <gl/glcorearb.h>
 #              if BX_PLATFORM_OSX
-#                      define GL_ARB_shader_objects // OSX collsion with GLhandleARB in gltypes.h
+#                      include <OpenGL/glext.h>
 #              endif // BX_PLATFORM_OSX
 #      else
 #              if BX_PLATFORM_LINUX || BX_PLATFORM_BSD

then it builds, but apparently this isn't correct fix and i can't actually check if build works because i don't have OSX.
I've searched through MacOS SDKs and the only place where i could find GL_SRGB_ALPHA_EXT was glext.h. However this compiles fine on Linux and i'm not sure where GL_SRGB_ALPHA_EXT is coming from. I thought i'm compiling everything from single monorepo with headers from bgfx/3rdparty/khronos, but apparently GL_SRGB_ALPHA_EXT is coming from system-installed headers, or GL headers are organized somehow differently on Linux (GLX).
Same problem appears when i'm cross-compiling for Windows using mingw-w64 with GCC 9:
... bgfx/src/renderer_gl.cpp: In member function 'bool bgfx::gl::RendererContextGL::init(const bgfx::Init&)':
... bgfx/src/renderer_gl.cpp:2068:51: error: 'GL_SRGB_ALPHA_EXT' was not declared in this scope; did you mean 'GL_SRGB_ALPHA'?
 2068 |        setTextureFormatSrgb(TextureFormat::RGBA8, GL_SRGB_ALPHA_EXT, GL_SRGB_ALPHA_EXT);
      |                                                   ^~~~~~~~~~~~~~~~~
      |                                                   GL_SRGB_ALPHA
... bgfx/src/renderer_gl.cpp:2069:50: error: 'GL_SRGB_EXT' was not declared in this scope; did you mean 'GL_SR8_EXT'?
 2069 |        setTextureFormatSrgb(TextureFormat::RGB8, GL_SRGB_EXT, GL_SRGB_EXT);
      |                                                  ^~~~~~~~~~~
      |                                                  GL_SR8_EXT

I can "fix" it by including gl/glext.h, which also fits OSX build problem, but, again, perhaps this is incorrect fix.
Any suggestions how to approach this? Thanks in advance.

Your fix worked! Thanks for a quick workaround!

@alekseyt Grab and try the latest.

Yep, that works. It cross-compiled for OSX and Windows without issues. Thank you very much.


chore(api): add API for chart, view, geometry

Checklist

[ ] npm test passes
[ ] tests and/or benchmarks are included
[ ] commit message follows commit guidelines

Description of change

Pull Request Test Coverage Report for Build 751417802

0 of 76 (0.0%)  changed or added relevant lines in 7 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 0.0%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/chart/index.ts
0
2
0.0%

src/core.ts
0
2
0.0%

src/geometry/index.ts
0
2
0.0%

src/geometry/element.ts
0
8
0.0%

src/geometry/geometry.ts
0
11
0.0%

src/chart/chart.ts
0
17
0.0%

src/chart/view.ts
0
34
0.0%

Totals

Change from base Build 728826592:
0.0%

Covered Lines:
0

Relevant Lines:
78

💛  - Coveralls


About dataset

Hello!
Thank you very much for your RailSem19-dataset, which is very helpful to my research. Now I want to ask you two questions. First, if I want to add new categories to the RailSem19-dataset, what should I do? Second, I want to use my own original image data to create the same RailSem19-dataset as the dataset. What tools or methods should I use?
I look forward to your reply! Thank you very much for your contribution.

Hi, please see the associated paper regarding the methodology on how we created RailSem19:
http://openaccess.thecvf.com/content_CVPRW_2019/papers/WAD/Zendel_RailSem19_A_Dataset_for_Semantic_Rail_Scene_Understanding_CVPRW_2019_paper.pdf
If you are interested in the topic of merging/extending existing datasets with other categories: please see the https://github.com/ozendelait/rvc_devkit for hints on where to begin


Small fix to documentation

I believe the reason the example is not rendering correctly in the docs is because it's missing the linebreak between the end of the docstring and example.
Issue #, if available:
*Description of changes: Just adding a linebreak so that the example renders correctly in the docs.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Job PR-529-1 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-529/1/index.html


I have written a swap string program in c

I have been learning c program and practicing it for a while ,so i have written a c program to swap two strings .

This is my first pr and happy to contribute to open source

@flickerbot please merge the pr

Hello @flickerbot


Should CloudSDK validation be coupled with jdk validation?

CloudSdk#validateCloudSdk also validates that the system jdk points to a proper executable.
Should these be coupled like this? This causes all validation of the CloudSDK to fail on improper jdk config. Presumably not all usages of the SDK require this.

never mind - I guess its needed both for devappserver runs and staging - see https://github.com/GoogleCloudPlatform/appengine-plugins-core/pull/352

Ideally I would separate java sdk validation from cloud sdk validation.  Typically I would expect the running (IJ or Maven) to take responsibility for displaying an appropriate error if the java sdk is incorrectly configured.

yea. what do you think then about just removing the jdk check completely from this library like we discussed offline.
Like you said, it should be up to the clients (IJ for instance doesn't really need this validation since the actions that require the cloud sdk also already require a configured project jdk)?

I'm OK with this.
On Thu, Aug 10, 2017 at 3:54 PM, Etan Shaul<EMAIL_ADDRESS>wrote:

yea. what do you think then about just removing the jdk check completely
from this library like we discussed offline.
Like you said, it should be up to the clients (IJ for instance doesn't
really need this validation since the actions that require the cloud sdk
also already require a configured project jdk)?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/appengine-plugins-core/issues/441#issuecomment-321656202,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HUqfrhSxCE_c9ef8fJxoIOS7RBUSks5sW1_1gaJpZM4OznAP
.


ldapnomnom: 1.1.0 -> 1.2.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/lkarlslund/ldapnomnom/releases.
meta.description for ldapnomnom is: Tool to anonymously bruteforce usernames from Domain controllers
meta.homepage for ldapnomnom is: https://github.com/lkarlslund/ldapnomnom
meta.changelog for ldapnomnom is: https://github.com/lkarlslund/ldapnomnom/releases/tag/v1.2.0
Updates performed

Golang update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.2.0 in filename of file in /nix/store/rkq2d66pa9hc34jniwk0y90x65a7pnjl-ldapnomnom-1.2.0

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
ldapnomnom

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/5a5221b8cf00ba324e28e0e5b631fd3a546e3f35#ldapnomnom

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

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

1 package built:

ldapnomnom

Maintainer pings
cc @fabaff for testing.

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

1 package built:

ldapnomnom


Rename the project

Anonymous Networks was always a project name. "Anonymous" is misleading and causing confusion.
I'd like to rename the app to something better. Possibly with interplanetary inspiration behind the name :)
Suggestions welcome!

"Anonymous" is misleading and causing confusion.

some suggestions, but you should really pick whatever sings to you the most

deck (deck of a ship)
bridge (bridge of a ship)
starchat
spacechat
spacetalk
startalk -- though clash http://www.startalkradio.net/
ipc
ipchat
iptalk

Are you guys fine if InterPlanetary is used in the name?

yeah go for it, just ask before you select one as there may be some we're reserving-- though i might be tempted to use ipc or ipchat some day too. shrug

Hale-baked ideas: (IPRC) InterPlanetary Relay Chat, (ICN) InterPlanetary Chat Network, the (ICE) InterPlanetary Chat Network, IM (InterPlanetary Messenger), (ICS) InterPlanetary Chat Stream, (IC) InterPlanetary Chat

Trying out a new name, see master.


Better favicon

Let's be honest, this favicon I hacked together is... bad! If anyone has something better or decent designing skills, I would be very happy to integrate that instead!
If I don't get a contribution on this, I might try to do a v2 myself, it probably won't be that great either though!

This might be an interesting feat. Where would you like to get it?

How is this? I think it's not that great.

Hi Shreyans,
Thanks for your contribution! I really like your idea, I think this can be a good base. A few things come to my mind, the first is how much details your version has, I think the tiny time markers won't be that "nice" once the icon is small. I am thinking of a clock like this one (search for "time") might work nicely?
Also, we can probably move away from the official Wayland icon, we can use a generic "w" (rendered in an open source sans-serif font) on a yellow background (this time using the official yellow).
What do you think?

I agree that this will not look good when it is small but I think we should still use the Wayland Logo.


feat: added CID.create (#477)

1. Description

1.1. Checklist

[ ] The title of my PR starts with a Conventional Commit prefix (fix:, feat:, docs: etc).
[ ] I have read the Contributor Guide and followed the process outlined for submitting PRs.
[ ] I have updated/added tests for ALL new/updated/fixed functionality.
[ ] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
[ ] I have updated/added relevant examples in examples.

1.2. Breaking Change

[ ] Yes, this is a breaking change.
[ ] No, this is not a breaking change.

1.3. Related Issues

Codecov Report

Merging #478 (4d5da4d) into main (d370877) will decrease coverage by 0.30%.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##             main     #478      +/-   ##
==========================================
- Coverage   76.77%   76.47%   -0.30%
==========================================
  Files         172      171       -1
  Lines        1537     1509      -28
==========================================
- Hits         1180     1154      -26
+ Misses        357      355       -2

see 1 file with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Add new DbLibrary class

Currently, a library within dtf is just an import-able Python module, however, there are now 5+ libraries that act as a database helper for storing content in the .dbs/ directory. As you can imagine, there is a ton of code reuse and it's really messy. The purpose of the DbLibrary class will be to:

Force libraries to follow a certain formatting
Remove all code in modules for checking if the DB exists, and setting up a remote project (think diffing)
Remove code that is reused in libraries (like having to implement a drop when you could use a drop_all())

Initial commit here: https://github.com/android-dtf/dtf/commit/f09e4ad5a7b1ba8c5e9c988b405889b493621a14
I'm slowly migrating the various Db classes to use this, so this API is not stable yet.


Update visual-project-structure.md

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

Hi @hongju,
Thank you for fixing this typo!
#sign-off

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

Hi, @hongju -- thanks for catching that typo!
#sign-off


Generalized k-means initialization for LR Sinkhorn/Gromov-Wasserstein

Codecov Report

Merging #135 (d131077) into main (19c537e) will decrease coverage by 0.59%.
The diff coverage is 72.50%.

@@            Coverage Diff             @@
##             main     #135      +/-   ##
==========================================
- Coverage   83.30%   82.70%   -0.60%
==========================================
  Files          48       50       +2
  Lines        4715     4858     +143
  Branches      512      527      +15
==========================================
+ Hits         3928     4018      +90
- Misses        649      695      +46
- Partials      138      145       +7

Impacted Files
Coverage Δ

ott/core/discrete_barycenter.py
15.58% <ø> (ø)

ott/core/gw_barycenter.py
74.50% <ø> (ø)

ott/core/sinkhorn.py
98.02% <ø> (ø)

ott/core/initializers_lr.py
67.15% <43.56%> (-14.74%)
:arrow_down:

ott/geometry/graph.py
82.01% <50.00%> (+1.06%)
:arrow_up:

ott/core/sinkhorn_lr.py
93.96% <75.00%> (+0.52%)
:arrow_up:

ott/core/gromov_wasserstein.py
89.76% <84.37%> (-2.62%)
:arrow_down:

ott/core/quad_initializers.py
88.46% <88.46%> (ø)

ott/core/_math_utils.py
94.73% <94.73%> (ø)

ott/core/quad_problems.py
86.50% <97.61%> (-1.12%)
:arrow_down:

... and 3 more


User Story 15- As a Political Scientist, I require a feature that allows me to explore capital cities within a specific continent, sorted by population from largest to smallest, to study regional governance structures, analyse political dynamics, and investigate factors influencing capital city development across continents.

tasks to complete
Connect to the existing database.
Add function to retrieve data on population
Add function to retrieve data on capital cities
Add function to retrieve data on continents
Generate report

SELECT population, name AS CapitalCity, continent
FROM country;


Feature Request: when --target-port is specified, default to --ingress=external

When the user specifies a --target-port they're clearly expecting to get traffic into their app so in cases where they don't also don't specify an --ingress value I'd like to suggest that we default it to --ingress=external.
This will give the best user-experience for new folks to the project since they would then not need to debug things to figure out why their app isn't getting traffic, or why they don't have an external URL associated with their app.
It means their app create command should be something as trivial as (if combined with #169):
$ az containerapp create -n myapp --image nginx --port 80

which is pretty nice and minimal for a 1st experience.
I didn't add the "CLI:" prefix to the issue because I think we should support this via the REST APIs too so it's more of a backend issue.

Hi @duglin, we're going to close this issue. If you'd like us to reconsider the ask, please reopen!


Create optional ServiceMonitor for Netbox

The Prometheus-Operator is a popular choice for collecting metrics, and many other projects (such as External-DNS [1]) have a pre-configured ServiceMonitor resource ready to be enabled; this does the same for Netbox.
The template is very heavily inspired by the External-DNS one.
1: https://github.com/kubernetes-sigs/external-dns/blob/master/charts/external-dns/templates/servicemonitor.yaml

Tested with local rendering of templates then applying to a given cluster - this is doing the trick for me, so hopefully it'll be helpful for others, too.

D'oh, didn't see #92 which does functionally the same thing. However, this doesn't introduce a breaking change, so might be preferred - feel free to approve/comment/close/other as you see fit, Chris.


Get rid of logging gem

Match the changes in the zookeeper gem to get rid of the logger gem.

Tried this in production and it's been good.

FYI: This changes breaks zk-server - https://github.com/zk-ruby/zk-server/pull/8


test_timeline_deletion_with_files_stuck_in_upload_queue flakyness after removing layer_removal_cs

https://neon-github-public-dev.s3.amazonaws.com/reports/main/7022163972/index.html#suites/837740b64a53e769572c4ed7b7a7eeeb/c9523cd005a770af
This now happens because #5108 added a RemoteTimelineClient::shutdown. I am unsure why would we do a http request for this after shutting down.

This is probably completed already.


Atmosphere doesn't have the latest updates to the package.

Can you fix atmosphere versioning to make it download the latest version of the package by default?

On contrary. It seems that Atmosphere has 2.0.3 published on January 14th, 2016, but this repository has only version 2.0.2. Please push the version 2.0.3 to the repository.


[Event Request] Codeunit 80 Sales-Post - OnBeforeCreateServItemOnSalesLineShpt

Hi Team,
In Codeunit 80 we need possibility to have our additional checks, standard publisher OnInvoiceSalesShptLine can not suit our needs, because it is called in two places, plus additional params would be required . Having event with handler in procedure InsertShipmentLine would be a perfect solution :

[IntegrationEvent(false, false)]
local procedure OnBeforeCreateServItemOnSalesLineShpt(var SalesHeader: Record "Sales Header"; var SalesShipmentLine: Record "Sales Shipment Line"; SalesShptHeader: Record "Sales Shipment Header"; xSalesLine: Record "Sales Line"; var IsHandled: Boolean)

Is it possible to use the existing event OnBeforeCreateServItemOnSalesLineShpt of codeunit codeunit 5920 ServItemManagement?

I'm closing this request as no response have bene provided for 4 weeks. I assume you can use suggestion. If not please create new request.


refactor: clean up some usages of with_labels

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#3854  👈
#3853
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Boshen and the rest of your teammates on  Graphite


Add-on is shutting down

Hi can't start the addon anymore since upgrading to 2.0.0
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for user-defined encoding conversions              ok
Checking for user-defined postfix operators                 ok
Creating dump of global objects                             ok
Creating dump of database schemas
  dsmrreader
  homeassistant
  postgres
  template1
                                                            ok
Checking for presence of required libraries                 fatal
Your installation references loadable libraries that are missing from the
new installation.  You can add these libraries to the new installation,
or remove the functions using them from the old installation.  A list of
problem libraries is in the file:
    loadable_libraries.txt
Failure, exiting
[15:30:43] ERROR: PostgreSQL could not upgrade! Please inspect any errors in the lines above!
[15:30:43] ERROR: Upgrade was not succesfull.
[cont-init.d] init.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] 99-message.sh: executing...
-----------------------------------------------------------
                Oops! Something went wrong.

 We are so sorry, but something went terribly wrong when
 starting or running this add-on.

 Be sure to check the log above, line by line, for hints.
-----------------------------------------------------------
[cont-finish.d] 99-message.sh: exited 0.
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

How do iI access the loadable_libraries.txt?

The file loadable_libraries.txt should be inside the container. You can start a shell inside the container with the Portainer AddOn.
Install and start the WebUI then go to Containers and search for the timescaledb container.

Press on the fourth icon to start the shell inside the container.

If I could get a hand on that file, I could see what library he is talking about, and maybe compile it in.
Also, what architecture are you on?

I have the same problem when I upgrade.
I have downgrade it to the previous version and it works again
Iam on a Nuc with hass only on it

After a full reboot this issue was gone and then I had the same issue as in #15. Because of that I downgraded the add on with a backup. It's now running smoothly again.

@Sholofly , the postgis message is not fatal.
It's just trying to upgrade postgis just to be sure, otherwise the upgrade process would fail.
Can you confirm this? Or do you still have update issues?

Same issue here or is the upgrade taking long?
Data page checksums are disabled.
fixing permissions on existing directory /data/postgres ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... UTC
creating configuration files ... ok
running bootstrap script ... ok
sh: locale: not found
2022-04-02 19:04:31.507 UTC [343] WARNING:  no usable system locales were found
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success.
initdb: warning: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
[21:04:35] INFO: done
[21:04:35] NOTICE: Upgrading PostgreSql...
[21:04:35] INFO: Starting PostgreSQL-12 first..
2022-04-02 19:04:35.430 UTC [355] LOG:  starting PostgreSQL 12.10 on x86_64-alpine-linux-musl, compiled by gcc (Alpine 10.3.1_git20211027) 10.3.1 20211027, 64-bit
2022-04-02 19:04:35.431 UTC [355] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2022-04-02 19:04:35.431 UTC [355] LOG:  listening on IPv6 address "::", port 5432
2022-04-02 19:04:35.449 UTC [355] LOG:  listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2022-04-02 19:04:35.468 UTC [355] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2022-04-02 19:04:35.506 UTC [360] LOG:  database system was shut down at 2022-04-02 19:04:23 UTC
2022-04-02 19:04:35.520 UTC [355] LOG:  database system is ready to accept connections
2022-04-02 19:04:35.525 UTC [366] LOG:  TimescaleDB background worker launcher connected to shared catalogs
[21:04:36] INFO: Upgrading Timescale extentions..
[21:04:36] INFO: Updating Timescale Extension for database system databases..
2022-04-02 19:04:36.440 UTC [368] LOG:  terminating TimescaleDB job scheduler due to administrator command
2022-04-02 19:04:36.441 UTC [368] FATAL:  terminating connection due to administrator command
2022-04-02 19:04:36.443 UTC [355] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 368) exited with exit code 1
terminating TimescaleDB scheduler entrypoint due to administrator command2022-04-02 19:04:37.155 UTC [382] FATAL:  terminating connection due to administrator command
2022-04-02 19:04:37.156 UTC [355] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 382) exited with exit code 1
ALTER EXTENSION
terminating TimescaleDB scheduler entrypoint due to administrator command2022-04-02 19:04:37.998 UTC [387] FATAL:  terminating connection due to administrator command
2022-04-02 19:04:37.999 UTC [355] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 387) exited with exit code 1
2022-04-02 19:04:38.032 UTC [389] ERROR:  TimescaleDB background worker connected to template database, exiting
2022-04-02 19:04:38.033 UTC [355] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 389) exited with exit code 1
ALTER EXTENSION
[21:04:38] INFO: Updating Timescale Extension for database: 'homeassistant'
2022-04-02 19:04:38.137 UTC [371] LOG:  terminating TimescaleDB job scheduler due to administrator command
2022-04-02 19:04:38.137 UTC [371] FATAL:  terminating connection due to administrator command
2022-04-02 19:04:38.138 UTC [355] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 371) exited with exit code 1
terminating TimescaleDB scheduler entrypoint due to administrator command2022-04-02 19:04:39.010 UTC [398] FATAL:  terminating connection due to administrator command
2022-04-02 19:04:39.011 UTC [355] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 398) exited with exit code 1
ALTER EXTENSION
[21:04:39] INFO: done
2022-04-02 19:04:39.058 UTC [355] LOG:  received smart shutdown request
2022-04-02 19:05:35.584 UTC [441] FATAL:  the database system is shutting down
2022-04-02 19:05:36.340 UTC [443] FATAL:  the database system is shutting down
2022-04-02 19:05:37.578 UTC [445] FATAL:  the database system is shutting down
2022-04-02 19:05:39.574 UTC [447] FATAL:  the database system is shutting down
2022-04-02 19:05:41.438 UTC [449] FATAL:  the database system is shutting down
2022-04-02 19:05:41.586 UTC [450] FATAL:  the database system is shutting down
2022-04-02 19:05:43.579 UTC [453] FATAL:  the database system is shutting down
2022-04-02 19:05:45.581 UTC [455] FATAL:  the database system is shutting down
2022-04-02 19:05:46.536 UTC [457] FATAL:  the database system is shutting down
2022-04-02 19:05:47.577 UTC [459] FATAL:  the database system is shutting down
2022-04-02 19:05:49.574 UTC [461] FATAL:  the database system is shutting down
2022-04-02 19:05:51.574 UTC [463] FATAL:  the database system is shutting down
2022-04-02 19:05:51.636 UTC [465] FATAL:  the database system is shutting down
2022-04-02 19:05:53.569 UTC [467] FATAL:  the database system is shutting down
2022-04-02 19:05:55.563 UTC [469] FATAL:  the database system is shutting down
2022-04-02 19:05:56.616 UTC [471] FATAL:  the database system is shutting down
2022-04-02 19:05:56.647 UTC [472] FATAL:  the database system is shutting down
2022-04-02 19:05:56.735 UTC [473] FATAL:  the database system is shutting down
2022-04-02 19:06:01.831 UTC [478] FATAL:  the database system is shutting down
2022-04-02 19:06:06.966 UTC [482] FATAL:  the database system is shutting down
2022-04-02 19:06:12.080 UTC [487] FATAL:  the database system is shutting down
2022-04-02 19:06:17.192 UTC [491] FATAL:  the database system is shutting down
2022-04-02 19:06:22.295 UTC [496] FATAL:  the database system is shutting down
2022-04-02 19:06:27.394 UTC [501] FATAL:  the database system is shutting down
2022-04-02 19:06:32.501 UTC [505] FATAL:  the database system is shutting down
2022-04-02 19:06:37.610 UTC [510] FATAL:  the database system is shutting down
2022-04-02 19:06:38.052 UTC [511] FATAL:  the database system is shutting down
2022-04-02 19:06:42.709 UTC [515] FATAL:  the database system is shutting down
2022-04-02 19:06:47.811 UTC [520] FATAL:  the database system is shutting down
2022-04-02 19:06:52.911 UTC [524] FATAL:  the database system is shutting down
2022-04-02 19:06:58.013 UTC [529] FATAL:  the database system is shutting down
2022-04-02 19:07:03.120 UTC [533] FATAL:  the database system is shutting down
2022-04-02 19:07:08.232 UTC [538] FATAL:  the database system is shutting down
2022-04-02 19:07:13.338 UTC [543] FATAL:  the database system is shutting down
2022-04-02 19:07:18.442 UTC [547] FATAL:  the database system is shutting down
2022-04-02 19:07:23.553 UTC [552] FATAL:  the database system is shutting down
2022-04-02 19:07:28.657 UTC [556] FATAL:  the database system is shutting down
2022-04-02 19:07:33.757 UTC [561] FATAL:  the database system is shutting down
2022-04-02 19:07:38.861 UTC [566] FATAL:  the database system is shutting down
2022-04-02 19:07:43.970 UTC [570] FATAL:  the database system is shutting down
2022-04-02 19:07:49.075 UTC [575] FATAL:  the database system is shutting down
2022-04-02 19:07:54.179 UTC [579] FATAL:  the database system is shutting down
2022-04-02 19:07:59.280 UTC [584] FATAL:  the database system is shutting down
2022-04-02 19:08:04.383 UTC [588] FATAL:  the database system is shutting down
2022-04-02 19:08:09.490 UTC [593] FATAL:  the database system is shutting down
2022-04-02 19:08:14.596 UTC [597] FATAL:  the database system is shutting down

Indeed, the system is being shutdown from outside, and could not complete it's upgrade.
What are your system specs? I will try to test with synthetic extra delays to reproduce

I have the same issue. The loadable-libraries.txt shows the following:
could not load library "$libdir/timescaledb-1.7.4": ERROR:  could not access file "$libdir/timescaledb-1.7.4": No such file or directory
In database: dsmrreader

Hi @arjen-w,
Do you have enough free disk space to perform the upgrade?
ERROR: tried calling catalog_get when extension looks like na old error: https://github.com/timescale/timescaledb/issues/1682#issuecomment-1084871322
If so, could you please pass the file-copy of the addon so I can investigate.

After investigating all your logs, I think I could identify 2 issues:

During Upgrade: ERROR: tried calling catalog_get when extension isn't loaded.

This is a timescale-bug (https://github.com/timescale/timescaledb/issues/1682#issuecomment-1084871322) that sometimes seems triggered. Perhaps due to low disk-space during upgrade?

Upgrade was aborted with error, after reboot a "clean installation" is performed by the addon.

Errors like Your installation references loadable libraries that are missing from the new installation are observed.
This seems to be related to the 2-step upgrade process of the timescale add-on.
First, the addon starts an old postgresql 12 server, and tries to update timescale to 2.6, otherwise pg_update cannot upgrade.
Next, a full upgrade to Postgresql 14 is performed, using the Postgresql 14 version of Timescale.
This first step is failing, and it looks like the upgrade to Timescale 2.6 fails because the database is actively being used (thus, the  timescale addon is being loaded).
To fix this, I'm building a new update that tries to block incoming connections during this process...

Thanks for following this up - if there's a gist with the procedure to retry the upgrade process with original data I'd be happy to give it a whirl.

Hi @arjen-w,
Do you have enough free disk space to perform the upgrade?
ERROR: tried calling catalog_get when extension looks like na old error: timescale/timescaledb#1682 (comment)
If so, could you please pass the file-copy of the addon so I can investigate.

I defintely do have enough diskspace.
I can provide a copy of the failed upgrade and a copy of the current add-on.
Do you want them as an HA backup or just as a plain file copy (zipped)?

@arjen-w a plan zipped copy fill do fine. All files and logfiles there! Thanks so much!

you should be able to download it from here: https://1drv.ms/u/s!ArMQ8sywUxlQiuIRvO3bmWkLXxwFKQ PAssword is timescaledb

Problem is still present in 2.0.1
`Performing Consistency Checks
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for user-defined encoding conversions              ok
Checking for user-defined postfix operators                 ok
Creating dump of global objects                             ok
Creating dump of database schemas
dsmrreader
homeassistant
postgres
template1
ok
Checking for presence of required libraries                 fatal
Your installation references loadable libraries that are missing from the
new installation.  You can add these libraries to the new installation,
or remove the functions using them from the old installation.  A list of
problem libraries is in the file:
loadable_libraries.txt
Failure, exiting
[15:27:08] ERROR: PostgreSQL could not upgrade! Please inspect any errors in the lines above!
[15:27:08] ERROR: Upgrade was not succesfull.
[cont-init.d] init.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] 99-message.sh: executing...
            Oops! Something went wrong.

We are so sorry, but something went terribly wrong when
starting or running this add-on.
Be sure to check the log above, line by line, for hints.
[cont-finish.d] 99-message.sh: exited 0.
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.`

Also here on 2.0.1 it is not working
--auth-local and --auth-host, the next time you run initdb.
syncing data to disk ... ok
Success.
[15:59:12] INFO: done
[15:59:12] NOTICE: Upgrading PostgreSql...
[15:59:12] INFO: Starting PostgreSQL-12 first..
2022-04-05 13:59:12.545 UTC [356] LOG:  starting PostgreSQL 12.10 on x86_64-alpine-linux-musl, compiled by gcc (Alpine 10.3.1_git20211027) 10.3.1 20211027, 64-bit
2022-04-05 13:59:12.545 UTC [356] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2022-04-05 13:59:12.545 UTC [356] LOG:  listening on IPv6 address "::", port 5432
2022-04-05 13:59:12.563 UTC [356] LOG:  listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2022-04-05 13:59:12.581 UTC [356] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2022-04-05 13:59:12.627 UTC [361] LOG:  database system was shut down at 2022-04-05 13:58:40 UTC
2022-04-05 13:59:12.643 UTC [356] LOG:  database system is ready to accept connections
2022-04-05 13:59:12.645 UTC [367] LOG:  TimescaleDB background worker launcher connected to shared catalogs
[15:59:13] INFO: Upgrading Timescale extentions..
[15:59:13] INFO: Updating Timescale Extension for database system databases..
NOTICE:  version "2.6.0" of extension "timescaledb" is already installed
ALTER EXTENSION
ALTER EXTENSION
NOTICE:  version "2.6.0" of extension "timescaledb" is already installed
[15:59:13] INFO: Updating Timescale Extension for database: 'homeassistant'
NOTICE:  version "2.6.0" of extension "timescaledb" is already installed
ALTER EXTENSION
[15:59:13] INFO: done
2022-04-05 13:59:13.652 UTC [356] LOG:  received smart shutdown request
2022-04-05 13:59:13.663 UTC [373] LOG:  terminating TimescaleDB job scheduler due to administrator command
2022-04-05 13:59:13.663 UTC [374] LOG:  terminating TimescaleDB job scheduler due to administrator command
2022-04-05 13:59:13.663 UTC [372] LOG:  terminating TimescaleDB job scheduler due to administrator command
2022-04-05 13:59:13.664 UTC [374] FATAL:  terminating connection due to administrator command
2022-04-05 13:59:13.664 UTC [372] FATAL:  terminating connection due to administrator command
2022-04-05 13:59:13.664 UTC [369] LOG:  terminating TimescaleDB job scheduler due to administrator command
2022-04-05 13:59:13.664 UTC [369] FATAL:  terminating connection due to administrator command
2022-04-05 13:59:13.665 UTC [371] LOG:  terminating TimescaleDB job scheduler due to administrator command
2022-04-05 13:59:13.665 UTC [371] FATAL:  terminating connection due to administrator command
2022-04-05 13:59:13.665 UTC [373] FATAL:  terminating connection due to administrator command
2022-04-05 13:59:13.666 UTC [370] LOG:  terminating TimescaleDB job scheduler due to administrator command
2022-04-05 13:59:13.666 UTC [370] FATAL:  terminating connection due to administrator command
2022-04-05 13:59:13.666 UTC [356] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 374) exited with exit code 1
terminating TimescaleDB background worker launcher due to administrator command2022-04-05 13:59:13.668 UTC [356] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 370) exited with exit code 1
2022-04-05 13:59:13.668 UTC [367] FATAL:  terminating connection due to administrator command
2022-04-05 13:59:13.668 UTC [356] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 371) exited with exit code 1
2022-04-05 13:59:13.668 UTC [356] LOG:  background worker "logical replication launcher" (PID 368) exited with exit code 1
2022-04-05 13:59:13.668 UTC [356] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 373) exited with exit code 1
2022-04-05 13:59:13.669 UTC [372] LOG:  terminating TimescaleDB job scheduler due to administrator command
2022-04-05 13:59:13.669 UTC [356] LOG:  background worker "TimescaleDB Background Worker Launcher" (PID 367) exited with exit code 1
2022-04-05 13:59:13.669 UTC [356] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 369) exited with exit code 1
2022-04-05 13:59:13.670 UTC [356] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 372) exited with exit code 1
2022-04-05 13:59:13.670 UTC [362] LOG:  shutting down
2022-04-05 13:59:13.762 UTC [356] LOG:  database system is shut down
[15:59:13] NOTICE: Upgrading databases..
Performing Consistency Checks
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for user-defined encoding conversions              ok
Checking for user-defined postfix operators                 ok
Creating dump of global objects                             ok
Creating dump of database schemas
dsmrreader
dsmrreader2
dsmrreaderltem
homeassistant
metabase
postgres
template1
ok
Checking for presence of required libraries                 fatal
Your installation references loadable libraries that are missing from the
new installation.  You can add these libraries to the new installation,
or remove the functions using them from the old installation.  A list of
problem libraries is in the file:
loadable_libraries.txt
Failure, exiting
[15:59:21] ERROR: PostgreSQL could not upgrade! Please inspect any errors in the lines above!
[15:59:21] ERROR: Upgrade was not succesfull.
[cont-init.d] init.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] 99-message.sh: executing...
            Oops! Something went wrong.

We are so sorry, but something went terribly wrong when
starting or running this add-on.
Be sure to check the log above, line by line, for hints.
[cont-finish.d] 99-message.sh: exited 0.
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.

Got the same as above 2.0.1 still fails.
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... UTC
creating configuration files ... ok
running bootstrap script ... ok
sh: locale: not found
2022-04-05 18:13:36.332 UTC [344] WARNING:  no usable system locales were found
performing post-bootstrap initialization ... ok
initdb: warning: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
syncing data to disk ... ok
Success.
[20:13:36] INFO: done
[20:13:36] NOTICE: Upgrading PostgreSql...
[20:13:36] INFO: Starting PostgreSQL-12 first..
2022-04-05 18:13:36.988 UTC [357] LOG:  starting PostgreSQL 12.10 on x86_64-alpine-linux-musl, compiled by gcc (Alpine 10.3.1_git20211027) 10.3.1 20211027, 64-bit
2022-04-05 18:13:36.989 UTC [357] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2022-04-05 18:13:36.989 UTC [357] LOG:  listening on IPv6 address "::", port 5432
2022-04-05 18:13:36.993 UTC [357] LOG:  listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2022-04-05 18:13:36.997 UTC [357] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2022-04-05 18:13:37.007 UTC [362] LOG:  database system was shut down at 2022-04-05 18:13:11 UTC
2022-04-05 18:13:37.011 UTC [357] LOG:  database system is ready to accept connections
2022-04-05 18:13:37.013 UTC [368] LOG:  TimescaleDB background worker launcher connected to shared catalogs
[20:13:37] INFO: Upgrading Timescale extentions..
[20:13:37] INFO: Updating Timescale Extension for database system databases..
NOTICE:  version "2.6.0" of extension "timescaledb" is already installed
ALTER EXTENSION
NOTICE:  version "2.6.0" of extension "timescaledb" is already installed
ALTER EXTENSION
[20:13:38] INFO: Updating Timescale Extension for database: 'homeassistant'
NOTICE:  version "2.6.0" of extension "timescaledb" is already installed
ALTER EXTENSION
[20:13:38] INFO: done
2022-04-05 18:13:38.043 UTC [357] LOG:  received smart shutdown request
2022-04-05 18:13:38.047 UTC [372] LOG:  terminating TimescaleDB job scheduler due to administrator command
2022-04-05 18:13:38.047 UTC [371] LOG:  terminating TimescaleDB job scheduler due to administrator command
2022-04-05 18:13:38.047 UTC [371] FATAL:  terminating connection due to administrator command
2022-04-05 18:13:38.048 UTC [370] LOG:  terminating TimescaleDB job scheduler due to administrator command
2022-04-05 18:13:38.048 UTC [372] FATAL:  terminating connection due to administrator command
terminating TimescaleDB background worker launcher due to administrator command2022-04-05 18:13:38.049 UTC [368] FATAL:  terminating connection due to administrator command
2022-04-05 18:13:38.049 UTC [370] FATAL:  terminating connection due to administrator command
2022-04-05 18:13:38.049 UTC [357] LOG:  background worker "logical replication launcher" (PID 369) exited with exit code 1
2022-04-05 18:13:38.049 UTC [370] LOG:  terminating TimescaleDB job scheduler due to administrator command
2022-04-05 18:13:38.049 UTC [357] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 371) exited with exit code 1
2022-04-05 18:13:38.049 UTC [357] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 372) exited with exit code 1
2022-04-05 18:13:38.050 UTC [357] LOG:  background worker "TimescaleDB Background Worker Launcher" (PID 368) exited with exit code 1
2022-04-05 18:13:38.051 UTC [357] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 370) exited with exit code 1
2022-04-05 18:13:38.051 UTC [363] LOG:  shutting down
2022-04-05 18:13:38.072 UTC [357] LOG:  database system is shut down
[20:13:38] NOTICE: Upgrading databases..
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for user-defined encoding conversions              ok
Checking for user-defined postfix operators                 ok
Creating dump of global objects                             ok
Creating dump of database schemas
  dsmrreader
  homeassistant
  postgres
  template1
                                                            ok
Checking for presence of required libraries                 fatal
Your installation references loadable libraries that are missing from the
new installation.  You can add these libraries to the new installation,
or remove the functions using them from the old installation.  A list of
problem libraries is in the file:
    loadable_libraries.txt
Failure, exiting
[20:13:40] ERROR: PostgreSQL could not upgrade! Please inspect any errors in the lines above!
[20:13:40] ERROR: Upgrade was not succesfull.
[cont-init.d] init.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] 99-message.sh: executing...
-----------------------------------------------------------
                Oops! Something went wrong.

 We are so sorry, but something went terribly wrong when
 starting or running this add-on.

 Be sure to check the log above, line by line, for hints.
-----------------------------------------------------------
[cont-finish.d] 99-message.sh: exited 0.
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

Hey... wait! @deku-m, @arjen-w, @bartbakels and @mgiebels,
Do you have your timescale-capable databases listed in the configuration-section?
If not, can you fill them in?
The addon loops trough this list to determine what databases actually use Timescale, and upgrades the timescale addon only in those databases, before trying to do the conversion to Postgres 14.

In the add-on dump from @arjen-w  (thanks again! really helpful!) I see this error in the loadable_libraries.txt:
could not load library "$libdir/timescaledb-1.7.4": ERROR:  could not access file "$libdir/timescaledb-1.7.4": No such file or directory In database: dsmrreader
But not in other databases....

@Expaso both databases are timescale enabled and I have the same problems as mentioned above.

@Simanias, could you post the error message from the loadable_libraries.txt file? It's located within the addon in the /data/postgres directory after the addon tried to upgrade.
It will tell what database is flawed, and what add-on version he is trying to load.
For all the above, it's trying to load the old timescale version (1.7.4) instead of 2.6.0.
Or can you post a screenshot from pg_admin and view the extensions, like so:

Hey... wait! @deku-m, @arjen-w, @bartbakels and @mgiebels,
Do you have your timescale-capable databases listed in the configuration-section? If not, can you fill them in? The addon loops trough this list to determine what databases actually use Timescale, and upgrades the timescale addon only in those databases, before trying to do the conversion to Postgres 14.

In the add-on dump from @arjen-w (thanks again! really helpful!) I see this error in the loadable_libraries.txt:
could not load library "$libdir/timescaledb-1.7.4": ERROR: could not access file "$libdir/timescaledb-1.7.4": No such file or directory In database: dsmrreader
But not in other databases..

@Expaso both databases are timescale enabled and I have the same problems as mentioned above.

Same here. databases are listed as shown by @Simanias .
Error is indeed looking for extension 1.7.4
My screenshot of PgAdmin:

Hi @arjen-w,
I am really trying to wrap my head around this: In the archive you sent me, the dsmrreader database is not in the timescale-enabled list of the addon config:

And it is exactly this missing database that is complaining about the upgrade.
But in your screenshot, it's there in the list.
What is your state of the addon now? Are you running 1.1.6 with this database enabled?
Either way, I will try to see if I can just query this for the upgrade,  instead of relying on this list.

Hey... wait! @deku-m, @arjen-w, @bartbakels and @mgiebels,
Do you have your timescale-capable databases listed in the configuration-section? If not, can you fill them in? The addon loops trough this list to determine what databases actually use Timescale, and upgrades the timescale addon only in those databases, before trying to do the conversion to Postgres 14.

In the add-on dump from @arjen-w (thanks again! really helpful!) I see this error in the loadable_libraries.txt:
could not load library "$libdir/timescaledb-1.7.4": ERROR: could not access file "$libdir/timescaledb-1.7.4": No such file or directory In database: dsmrreader
But not in other databases....

HI,
Indeed at my side it was the timescale_enabled which was missing for dsmr.
Addon is now up and running.

HI,
Indeed at my side it was the timescale_enabled which was missing for dsmr. Addon is now up and running.

Same here! after adding it into the config lines, the upgrade went fine! Not sure how I missed that yesterday whilie I was checking that...

Sweet! 🥳! I thought I was going nuts! 🤯 ..
Thanks for your confirmation!
I have the code ready to not rely on this list, but instead query it out myself, just to be sure.
Can do the same for the Postgis exention (this clears some non-fatal but confusing errors from the logs).
Will test this out and launch in a couple of days, but at least it's not necessary for the upgrade process.
As you can see, it's not a trivial upgrade within the add-on itself. That's why it took a while ;).
I had to juggle multiple Postgres versions and extensions around in just the right mix with different architectures.
Unless Postgres 15 is around the corner, the updates will be minimal and focused again around TimescaleDB itself.
Thank you all for your support! 🙏

It didn't work for me and I just started over so I lost old data unfortunately.
After my upgrade to 2.0.1 it went wrong.
And a rollback also failed, he no longer starts.
And I don't get old data back either I work on Homeassistant on NUC but I don't work with docker installed it directly on the ssd.

I only keep getting the Postgis error. Apart from that everything works.

I only keep getting the Postgis error. Apart from that everything works.

This error is non-fatal. The addon tries to update this extension on all databases just to be sure.
I will push an update soon that will be a little bit more intelligent about this, but it's not fatal.

It didn't work for me and I just started over so I lost old data unfortunately. After my upgrade to 2.0.1 it went wrong. And a rollback also failed, he no longer starts. And I don't get old data back either I work on Homeassistant on NUC but I don't work with docker installed it directly on the ssd.

I can help you with this. I assume you did not press 'remove' on the addon? If not, your data is still there.
 Or are you running another form of supervised Home Assistant?

If the SQL backup was created using pg_dump, you could just do a pg_restore on a freshly installer add-on.

I do have timescale enabled on my dsmrreader db but still get an error

I have no idea actually this info is in there. (a part of the sql) † -- PostgreSQL database dump †
-- Dumped from database version 12.4 -- Dumped by pg_dump version 14.2
SET statement_timeout = 0; SET lock_timeout = 0; SET idle_in_transaction_session_timeout = 0; SET client_encoding = 'UTF8'; SET standard_conforming_strings = on; SELECT pg_catalog.set_config('search_path', '', false); SET check_function_bodies = false; SET xmloption = content; SET client_min_messages = warning; SET row_security = off;
I just wouldn't know how to do a restore and where because I can't access my computer via pgadmin

You can just use pg_restore as far as I can see, from any linux machine with Posgres 14 tools available. See also: https://www.postgresql.org/docs/9.2/app-pgrestore.html
Do you have access

After upgrading to 2.0, the addon wouldn't start. I restored a backup (1.6) but still no luck. Now i just upgraded to 2.1 but now i keep getting the same error
2022-04-07 16:32:43.772 UTC [576] FATAL:  password authentication failed for user "postgres" 2022-04-07 16:32:43.772 UTC [576] DETAIL:  User "postgres" has no password assigned
I cannot check in pgadmin since it keeps asking me for a password but there is none.
I'm running home assistant on a NUC with debian, docker and plenty of disk space
There is another topic with this problem but i read you would continue here. Maybe I overlooked but i'm seeing a solution to this specific problem

Sadly, 2.0.1 didn't fix this. Exactly the same error as before ("Checking for presence of required libraries                 fatal"). Due to time constraints I haven't been able to log in via root to examine the container, nor will the add-on remain up long enough for any pgadmin4 sanity checks.
RPi4 with HA OS.

I had problems upgrading to 2.0.0 (I wrote in #14) and restored from backup. Now, I just upgraded to 2.0.1 and it's working for me  👍

I restored a backup so i went back from 2.0 to 1.1.6 (so maybe i could upgrade to 2.0.1 in the next step) but even the backup is not really working
2022-04-10 08:30:02.992 UTC [411] LOG:  starting PostgreSQL 12.4 on x86_64-alpine-linux-musl, compiled by gcc (Alpine 9.3.0) 9.3.0, 64-bit
2022-04-10 08:30:02.992 UTC [411] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2022-04-10 08:30:02.992 UTC [411] LOG:  listening on IPv6 address "::", port 5432
2022-04-10 08:30:02.994 UTC [411] LOG:  listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2022-04-10 08:30:02.996 UTC [411] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2022-04-10 08:30:03.050 UTC [416] LOG:  database system was interrupted; last known up at 2022-03-31 13:32:18 UTC
2022-04-10 08:30:03.512 UTC [416] LOG:  invalid primary checkpoint record
2022-04-10 08:30:03.512 UTC [416] PANIC:  could not locate a valid checkpoint record
2022-04-10 08:30:03.954 UTC [419] FATAL:  the database system is starting up
2022-04-10 08:30:03.956 UTC [420] FATAL:  the database system is starting up
2022-04-10 08:30:04.969 UTC [425] FATAL:  the database system is starting up
2022-04-10 08:30:04.973 UTC [426] FATAL:  the database system is starting up
2022-04-10 08:30:06.059 UTC [431] FATAL:  the database system is starting up
2022-04-10 08:30:06.062 UTC [432] FATAL:  the database system is starting up
2022-04-10 08:30:07.079 UTC [437] FATAL:  the database system is starting up
2022-04-10 08:30:07.081 UTC [438] FATAL:  the database system is starting up
2022-04-10 08:30:08.094 UTC [443] FATAL:  the database system is starting up
2022-04-10 08:30:08.096 UTC [444] FATAL:  the database system is starting up
2022-04-10 08:30:09.103 UTC [449] FATAL:  the database system is starting up
2022-04-10 08:30:09.104 UTC [450] FATAL:  the database system is starting up
2022-04-10 08:30:10.045 UTC [411] LOG:  startup process (PID 416) was terminated by signal 6: Aborted
2022-04-10 08:30:10.046 UTC [411] LOG:  aborting startup due to startup process failure
2022-04-10 08:30:10.163 UTC [411] LOG:  database system is shut down

So i don't think there's any point in upgrading to 2.0.1 if the 1.1.6 version isn't working

Sadly, 2.0.1 didn't fix this. Exactly the same error as before ("Checking for presence of required libraries fatal"). Due to time constraints I haven't been able to log in via root to examine the container, nor will the add-on remain up long enough for any pgadmin4 sanity checks.
RPi4 with HA OS.

Have you checked that all timescale-enabled databases are listed in the 'timescale-enabled' section of the addon?

I restored a backup so i went back from 2.0 to 1.1.6 (so maybe i could upgrade to 2.0.1 in the next step) but even the backup is not really working
2022-04-10 08:30:02.992 UTC [411] LOG:  starting PostgreSQL 12.4 on x86_64-alpine-linux-musl, compiled by gcc (Alpine 9.3.0) 9.3.0, 64-bit
2022-04-10 08:30:02.992 UTC [411] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2022-04-10 08:30:02.992 UTC [411] LOG:  listening on IPv6 address "::", port 5432
2022-04-10 08:30:02.994 UTC [411] LOG:  listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2022-04-10 08:30:02.996 UTC [411] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2022-04-10 08:30:03.050 UTC [416] LOG:  database system was interrupted; last known up at 2022-03-31 13:32:18 UTC
2022-04-10 08:30:03.512 UTC [416] LOG:  invalid primary checkpoint record
2022-04-10 08:30:03.512 UTC [416] PANIC:  could not locate a valid checkpoint record
2022-04-10 08:30:03.954 UTC [419] FATAL:  the database system is starting up
2022-04-10 08:30:03.956 UTC [420] FATAL:  the database system is starting up
2022-04-10 08:30:04.969 UTC [425] FATAL:  the database system is starting up
2022-04-10 08:30:04.973 UTC [426] FATAL:  the database system is starting up
2022-04-10 08:30:06.059 UTC [431] FATAL:  the database system is starting up
2022-04-10 08:30:06.062 UTC [432] FATAL:  the database system is starting up
2022-04-10 08:30:07.079 UTC [437] FATAL:  the database system is starting up
2022-04-10 08:30:07.081 UTC [438] FATAL:  the database system is starting up
2022-04-10 08:30:08.094 UTC [443] FATAL:  the database system is starting up
2022-04-10 08:30:08.096 UTC [444] FATAL:  the database system is starting up
2022-04-10 08:30:09.103 UTC [449] FATAL:  the database system is starting up
2022-04-10 08:30:09.104 UTC [450] FATAL:  the database system is starting up
2022-04-10 08:30:10.045 UTC [411] LOG:  startup process (PID 416) was terminated by signal 6: Aborted
2022-04-10 08:30:10.046 UTC [411] LOG:  aborting startup due to startup process failure
2022-04-10 08:30:10.163 UTC [411] LOG:  database system is shut down

So i don't think there's any point in upgrading to 2.0.1 if the 1.1.6 version isn't working
EDIT: i took the gamble and upgraded the non-working version 1.1.6 and this is the result
2022-04-10 09:05:09.458 UTC [356] LOG:  starting PostgreSQL 12.10 on x86_64-alpine-linux-musl, compiled by gcc (Alpine 10.3.1_git20211027) 10.3.1 20211027, 64-bit
2022-04-10 09:05:09.458 UTC [356] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2022-04-10 09:05:09.458 UTC [356] LOG:  listening on IPv6 address "::", port 5432
2022-04-10 09:05:09.461 UTC [356] LOG:  listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2022-04-10 09:05:09.463 UTC [356] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2022-04-10 09:05:09.512 UTC [361] LOG:  database system was interrupted; last known up at 2022-03-31 13:32:18 UTC
2022-04-10 09:05:10.004 UTC [361] LOG:  invalid primary checkpoint record
2022-04-10 09:05:10.005 UTC [361] PANIC:  could not locate a valid checkpoint record
2022-04-10 09:05:10.456 UTC [363] FATAL:  the database system is starting up
2022-04-10 09:05:11.498 UTC [366] FATAL:  the database system is starting up
2022-04-10 09:05:12.526 UTC [369] FATAL:  the database system is starting up
2022-04-10 09:05:13.542 UTC [372] FATAL:  the database system is starting up
2022-04-10 09:05:14.554 UTC [375] FATAL:  the database system is starting up
2022-04-10 09:05:15.569 UTC [378] FATAL:  the database system is starting up
2022-04-10 09:05:16.581 UTC [381] FATAL:  the database system is starting up
2022-04-10 09:05:17.190 UTC [356] LOG:  startup process (PID 361) was terminated by signal 6: Aborted
2022-04-10 09:05:17.190 UTC [356] LOG:  aborting startup due to startup process failure
2022-04-10 09:05:17.305 UTC [356] LOG:  database system is shut down

I thought the 2.0 version of this addon came with PostgreSQL 14

Correct, this version comes with Postgres 14. But.. to upgrade from 12 to 14, there are a certain tricky steps involved, namely:

Upgrade timescale WHILE RUNNING Postgres 12
Upgrade Postgres from 12 to 14
Upgrade the rest of the addons

In your case, it looks like Postgres 12 was not correctly shut-down before trying the upgrade.
database system was interrupted; last known up at 2022-03-31 13:32:18 UTC
2022-04-10 08:30:03.512 UTC [416] LOG:  invalid primary checkpoint record
2022-04-10 08:30:03.512 UTC [416] PANIC:  could not locate a valid checkpoint record
Can you try again when the addon was shutdown properly?

Aha, thanks for that - somehow I missed that I needed to add my ltss db to the yaml config. Is it not possible to check for existing database timescaledb status programatically?
I also noted the following; apologies if this is also something I've missed.
2022-04-11 23:24:00.944 UTC [496] STATEMENT:  SELECT PostGIS_Extensions_Upgrade();
ERROR:  function postgis_extensions_upgrade() does not exist
LINE 1: SELECT PostGIS_Extensions_Upgrade();
^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
[09:24:00] INFO: Upgrading PostGIS for database: 'ha-ltss'
NOTICE:  Extension postgis_raster is not available or not packagable for some reason
NOTICE:  Extension postgis_topology is not available or not packagable for some reason
NOTICE:  Extension postgis_tiger_geocoder is not available or not packagable for some reason
postgis_extensions_upgrade
Upgrade completed, run SELECT postgis_full_version(); for details
(1 row)
[09:24:01] INFO: done

Correct, this version comes with Postgres 14. But.. to upgrade from 12 to 14, there are a certain tricky steps involved, namely:

Upgrade timescale WHILE RUNNING Postgres 12
Upgrade Postgres from 12 to 14
Upgrade the rest of the addons

In your case, it looks like Postgres 12 was not correctly shut-down before trying the upgrade.
database system was interrupted; last known up at 2022-03-31 13:32:18 UTC 2022-04-10 08:30:03.512 UTC [416] LOG: invalid primary checkpoint record 2022-04-10 08:30:03.512 UTC [416] PANIC: could not locate a valid checkpoint record
Can you try again when the addon was shutdown properly?

No luck. The upgrade breaks on starting PostgreSql 12.
[18:10:20] INFO: done
[18:10:20] NOTICE: Upgrading PostgreSql...
[18:10:20] INFO: Starting PostgreSQL-12 first..
2022-04-12 16:10:20.657 UTC [357] LOG:  starting PostgreSQL 12.10 on x86_64-alpine-linux-musl, compiled by gcc (Alpine 10.3.1_git20211027) 10.3.1 20211027, 64-bit
2022-04-12 16:10:20.658 UTC [357] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2022-04-12 16:10:20.658 UTC [357] LOG:  listening on IPv6 address "::", port 5432
2022-04-12 16:10:20.660 UTC [357] LOG:  listening on Unix socket "/run/postgresql/.s.PGSQL.5432"
2022-04-12 16:10:20.662 UTC [357] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2022-04-12 16:10:20.712 UTC [362] LOG:  database system was interrupted; last known up at 2022-03-31 13:32:18 UTC
2022-04-12 16:10:21.214 UTC [362] LOG:  invalid primary checkpoint record
2022-04-12 16:10:21.214 UTC [362] PANIC:  could not locate a valid checkpoint record
2022-04-12 16:10:21.647 UTC [364] FATAL:  the database system is starting up
2022-04-12 16:10:22.656 UTC [367] FATAL:  the database system is starting up
2022-04-12 16:10:23.666 UTC [370] FATAL:  the database system is starting up
2022-04-12 16:10:24.679 UTC [373] FATAL:  the database system is starting up
2022-04-12 16:10:25.694 UTC [376] FATAL:  the database system is starting up
2022-04-12 16:10:26.706 UTC [379] FATAL:  the database system is starting up
2022-04-12 16:10:27.722 UTC [382] FATAL:  the database system is starting up
2022-04-12 16:10:28.143 UTC [357] LOG:  startup process (PID 362) was terminated by signal 6: Aborted
2022-04-12 16:10:28.143 UTC [357] LOG:  aborting startup due to startup process failure
2022-04-12 16:10:28.265 UTC [357] LOG:  database system is shut down

It seems the database won't start because of that "invalid primary checkpoint record".
Would be a shame to lose this database. More than a year of Solar panel, energy consumption, ... data. And another database (,postgis, not timescale) for another project.

Hi, this is related to https://github.com/Expaso/hassos-addon-timescaledb/issues/14 - which is marked as closed. However, I don't think that the problem is really solved.
Over there, the recommended approach is to downgrade and then re-direct  a copy of the data directory.
If anyone has successfully done this, I would appreciate a step-by-step summary.

@kennethhaspeel Are you on Discord? If so, PM me at Expaso #3263 and I can try to guide you through it..
@dschien Maybe.. the upgrade process is protected against an error as in: when the upgrade fails, it will restore the data directories to it's old positions..but.. if Postgres fails to start due above conditions, the upgrade process is aborted too early and will not recover by itself. I am currently creating a config option to reboot this upgrade process.
Can you SSH into your homeassistant as in, port 2222 ?
I can help you to execute those steps by hand if you like, so you can continue right away.
Reach out on Discord: Expaso #3263 , I will try to help you get past the message.

https://discord.gg/SSdEdbAZ

No more people to help out? Closing issue! Thank you guys!


LogicTreeToolBox.toCNF() is not correct

For example, the following logical formula are not correctly converted into CNF:

(a or b or not(a))

expected result: b
returned result: true

(a or b or not(a) or not(a))

expected result: b
returned result: true

(a and not(b)) or (not(a) and b) or (not(a) and not(b))

expected result: (not(a) or not(b))
returned result: ((not(a) or not(b) or not(a)) and (not(b) or not(b) or not(a)))

I need a coffee...

Ok, the two first cases are tautologies.
The returned result of the last one is correct but could be simplified to  (not(a) or not(b)).


Input contains NaN, infinity or a value too large for dtype('float64').

x_train,x_val,y_train,y_val=train_test_split(input_predictors,output_target,test_size=0.20,random_state=7)
from sklearn.metrics import accuracy_score
from sklearn.linear_model import LogisticRegression
logreg=LogisticRegression()
x_train=x_train.astype(np.float64,copy=False)
y_train=y_train.astype(np.float64,copy=False)
logreg.fit(x_train,y_train)
when i write fit line it is showing:
ValueError: Input contains NaN, infinity or a value too large for dtype('float64').

Hello,How did you solve this problem? I have also encountered this problem. If you have solved it, could you please answer it?


[EncDecBuffer] Support for string

Is there any reason why EncDecBuffer does not support strings by default? I have come up with this:
static func write_string_utf8(encdecbuffer: EncDecBuffer, string: String) -> void:
	var bytes := string.to_utf8()
	encdecbuffer.write_uint(bytes.size())
	for i in bytes.size():
		encdecbuffer.write_byte(bytes[i])

static func read_string_utf8(encdecbuffer: EncDecBuffer) -> String:
	var bytes := PoolByteArray()
	var size := encdecbuffer.read_uint()
	for i in size:
		bytes.append(encdecbuffer.read_byte())
	return bytes.get_string_from_utf8()

(I am not using strings in snapshots but in custom player_data properties to optimize and send things like player name, skin etc. to be send in one packet)

The EncDecBuffer was meant primarily to strip out extra data attached to variables, which is part of the Variant. This extra data basically specifies which type is stored within the variant, and uses 4 bytes. I honestly didn't see any reason to encode/decode Strings in this system.
The thing is, sending the full variant data occasionally is not a problem. Sending this data at every single frame can be a problem as it will quickly escalate to very big numbers.
The custom player data is sent only during initial synchronization then only when changed. So, as long as changes are not too common (how often depends very much on the project and the desired "budget"), it should not be a problem.
Now you actually touched one point that I do intend to work at a later moment. Currently each custom property will be sent in a different packet and this is something I do want to fix.
In any case, this can indeed be added into the feature set of the addon. If you want (and feel comfortable with the idea), feel free to open a pull request.

Thanks for the info. That was the limitation for me because I wanted to send multiple configs at once when player connects.


Atom crashes on open

Prerequisites

[x] Can you reproduce the problem in safe mode?
[x] Are you running the latest version of Atom?
[x] Did you check the debugging guide?
[x] Did you check the FAQs on Discuss?
[x] Are you reporting to the correct repository?
[x] Did you perform a cursory search to see if your bug or enhancement is already reported?

Description
Atom crashes on open up, tried to do a re-install and still crashes
Steps to Reproduce

Open atom
Crash

Versions
Atom    : 1.8.0
Electron: 0.36.8
Chrome  : 47.0.2526.110
Node    : 5.1.1
npm  2.13.3
node 0.10.40
python 2.7.6
git 1.9.1
Linux ELI-PC 3.13.0-91-generic #138-Ubuntu SMP Fri Jun 24 17:00:34 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 14.04LTS
atom -f returns the following
[5833:0711/142520:ERROR:browser_main_loop.cc(203)] Running without the SUID sandbox!
Report Id:

Note: I just tried to re-run after deleting .atom dir and it seems to be running okay. Will update when/if I find the file responsible

Thanks for the update @ElliottJRo. I'm going to close this. Please let us know if you get more information, I'll be happy to reopen it if you can reproduce the problem reliably.


Default Context not being attached to logs. per documentation

Issue Report: LogDNA Browser Logging
Description
There is an issue with the logging mechanism in the LogDNA browser integration. The logs occasionally fail to capture the default context, including location, user information, environment, etc.
Example Log

LogDNA Initialization Code
const hostname = 'Tradeweb-User-Interface';
logdna.init(CONFIG.logDnaApiKey, {
  app: `Tradeweb-User-Interface`,
  env: CONFIG.env,
  hostname: hostname,
  enableStacktrace: true,
  enableIpAddress: true,
  console: CONFIG.logDnaEnabledLocally
});
if (CONFIG.logDnaEnabledLocally) {
  console.log = (message, ...optionalParams) => logdna.log({ message: chalk.green(message, JSON.stringify(optionalParams)) });
  console.error = (message, ...optionalParams) => logdna.error({ message: chalk.red(message, JSON.stringify(optionalParams)) });
  console.debug = (message, ...optionalParams) => logdna.debug({ message: chalk.blue(message, JSON.stringify(optionalParams)) });
  console.warn = (message, ...optionalParams) => logdna.warn({ message: chalk.yellow(message, JSON.stringify(optionalParams))});
  console.info = (message, ...optionalParams) => logdna.info({ message: chalk.cyan(message, JSON.stringify(optionalParams))});
}

Automatically Added Context (from documentation)
"sessionId": "d1b69ea3-41c4-4b9b-85e2-32fb94cb219c",
"browser": {
  "name": "chrome",
  "version": "87.0.4280",
  "os": "Mac OS",
  "type": "browser"
},
"location": {
  "ancestorOrigins": {},
  "href": "https://your-web-app/home?q=1234567890",
  "origin": "https://your-web-app",
  "protocol": "https:",
  "host": "your-web-app",
  "hostname": "your-web-app",
  "port": "",
  "pathname": "/home",
  "search": "?q=1234567890",
  "hash": ""
}

Expected Behavior
The logs should consistently capture the default context, including location, user information, environment, etc.

Looking at the message in the screen shot, it appears that this isnt an issue with the context not being captured but the line parser not being able to parse the data.  Here is more information https://docs.mezmo.com/docs/log-parsing

Looking at the message in the screen shot, it appears that this isnt an issue with the context not being captured but the line parser not being able to parse the data. Here is more information https://docs.mezmo.com/docs/log-parsing

this was the context i was attempting to use:

i tried varying variable name from userName, userEmail etc they all seem to fail even though all the values are always strings.
i attempted to follow the docs which show this:

which shows the ability to add an object for user. but when i attempt to do so their is a type error from the package:

where the calues must be of type ContextT:

this is me logging my context object in logdna:

in browser console:

the code doing the logging:

everything is consistently strings. so it is unclear to me the current issue with parsing.
no additional context provided by my app with the add context useEffect commented out:

If you look at the first screen shot, it appears that you are attempting to add the string "(app=Tradeweb-User-Interface<EMAIL_ADDRESS>env=ga, userName=Cypres Underwriter) " to the meta.context but meta.context expects an object and there is unable to parse it.
The indexer will reset ever 24 hours or so but during that time the data types should not change.  So if the first log that come through provides the meta.context as an object then the rest of the lines should be the same or if meta.context first got set as a string the every other time meta.context should be a string until it resets.

If you look at the first screen shot, it appears that you are attempting to add the string "(app=Tradeweb-User-Interface<EMAIL_ADDRESS>env=ga, userName=Cypres Underwriter) " to the meta.context but meta.context expects an object and there is unable to parse it. The indexer will reset ever 24 hours or so but during that time the data types should not change. So if the first log that come through provides the meta.context as an object then the rest of the lines should be the same or if meta.context first got set as a string the every other time meta.context should be a string until it resets.

so i have waited over 24hrs. saw the logs and the context work but then it stops. I am unsure how more consistent i can be with the context i am adding to always be strings. is the app wide issue? so if the issue is happening inconsistently with the types in dev, qa, beta, staging, production it would then break all the environments and wouldn't be fixed unless fixed in all the environments?
because this is what i changed my code to locally:
  useEffect(() => {
    if (auth.user && auth.user.email && auth.user.name && auth.isAuthenticated && !auth.isLoading) {
      logdna.clearContext();
      const logDnaContext = {
        env: `${CONFIG.env}`,
        app: 'Tradeweb-User-Interface',
        userName: `${auth.user.name}`,
        userEmail: `${auth.user.email}`
      }
      logdna.addContext(logDnaContext);
      console.log('logdna add context', logDnaContext);
    } else {
      logdna.clearContext();
      const logDnaContext = {
        env: `${CONFIG.env}`,
        app: 'Tradeweb-User-Interface',
        userName: `Not User`,
        userEmail: `No User`
      }
      logdna.addContext(logDnaContext);
      console.log('logdna add context', logDnaContext);
    }
  }, [auth.user, auth.isAuthenticated, auth.isAuthenticated])

If you look at the first screen shot, it appears that you are attempting to add the string "(app=Tradeweb-User-Interface<EMAIL_ADDRESS>env=ga, userName=Cypres Underwriter) " to the meta.context but meta.context expects an object and there is unable to parse it. The indexer will reset ever 24 hours or so but during that time the data types should not change. So if the first log that come through provides the meta.context as an object then the rest of the lines should be the same or if meta.context first got set as a string the every other time meta.context should be a string until it resets.

i create a new key and app name for me to test this out but i am still running into issues. like this:

i guess i am confused on how with a new key and app and the context being set is 100% always the same type which is strings. how the value types can be inconsistent

very first log with a new key, new hostname new app name:

I believe this index is for the entire account and not based on the specific key, host name or app name.  I will double check this and let you know if that is incorrect.


Allow JS functions to be imported inside of non-public modules

I wanted to access the JS console as console::log, so I attempted this:
#![feature(proc_macro, wasm_custom_section, wasm_import_module)]

extern crate wasm_bindgen;

mod console {
    use wasm_bindgen::prelude::*;

    #[wasm_bindgen]
    extern {
        #[wasm_bindgen(js_namespace = console)]
        pub fn log(s: &str);
    }
}

The compiler had this warning:
   Compiling imaj v0.1.0 (file:///private/tmp/imaj)
warning: function is marked #[no_mangle], but not exported
  --> src/lib.rs:12:5
   |
12 |     #[wasm_bindgen]
   |     ^^^^^^^^^^^^^^^
   |
   = note: #[warn(private_no_mangle_fns)] on by default

And wasm-bindgen had this to say:
$ wasm-bindgen target/wasm32-unknown-unknown/release/imaj.wasm --out-dir=.
thread 'main' panicked at 'failed to run export: Function("Module doesn\'t have export __wbindgen_describe___wbg_f_log_log_n")', libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Making the console module public worked, but it wasn't my goal to make it public.

rustc 1.27.0-nightly (acd3871ba 2018-05-10)
wasm-bindgen 0.2.10

See also #159

I unfortunately don't know of a great way to solve this, but if anyone else knows how to work around this I'd be more than willing to implement a solution!

I've started a branch at https://github.com/rustwasm/wasm-bindgen/tree/used to game out the usage of #[used] to hopefully overcome the restrictions here, although it's not quite working yet and I haven't had a chance to dig in

Ok I've ironed out various kinks in the branch and it looks like two more things are still needed to implement this:

First we need to upgrade LLD with --gc-sections. Otherwise the binaries keep too much information (a bunch of function pointers). Without --gc-sections we can't turn this on by default as it'll regress wasm sizes too much.
Second, it doesn't actually work! As we can see on the playground the functions are kept in the IR long enough to reach the linker, but they don't persist beyond that. The function is marked as internal when we want it not marked as internal, it needs to be a fully exported function. In that sense we don't have control over linkage visibility in stable Rust, so we'd need another strategy to pursue to get this working.


Make Banner for README.md

Need a Banner for README.md
The banner should describe the collaborative work of ICC & Pragmatic Programmer on this project by using the logo of ICC & Pragmatic Programmer.
Todo:

[ ] Assign issue to someone
[ ] Provide logos and theme

Discuss in discord server: https://discord.gg/bM9Wy6Yzn2

I'm willing


chore: bdd-nh-1592818960 to 0.0.1

chore: Promote bdd-nh-1592818960 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Implementing Persistence Query

https://github.com/okumin/akka-persistence-sql-async/issues/5

@okumin I'm concerned that asyncWriteMessages can't safely be written using asynchronous database writes.
Since AsyncWriteJournal is an actor, writing a message M1 to the database asynchronously can result in a subsequent write of message M2 being processed and persisted before the write of M1 has completed. While I don't think this will actually cause any errors to be thrown by the database, it does mean that reads from the database could return streams with missing data.
The LevelDb implementation avoids this by performing all state modifications and writes in a synchronous block of code that is simply wrapped with Future.fromTry { ... } which allows the synchronous code to conform to the async interface.
This obviously isn't perfect as it results in blocking the AsyncWriteJournal actor's thread but it does guarantee that there are no race conditions in side-effecting code.
Thoughts?

I have thought that any pair of asyncWriteMessages for the same persistence_id is not invoked at once and then the current implementation is safe since all the AtomicWrite is inserted in one transaction.

I can't find any documentation that seems to indicate that asyncWriteMessages will not be invoked concurrently for the same persistence_id and it's not obvious to me how that would be happening in AsyncWriteJournal.scala
Let me know if I've overlooked something.

It seems that PersistentActor writes one or batched events seqentially, but I would like to have more time to get the evidence.
https://github.com/akka/akka/blob/master/akka-persistence/src/main/scala/akka/persistence/Eventsourced.scala

You are right and we should serialize events by persistence id.
https://groups.google.com/forum/#!topic/akka-user/hi-OlSuO_M0

Created the issue for that topic.
https://github.com/okumin/akka-persistence-sql-async/issues/9

Is there any progress migrating this plugin to akka 2.5.x?

Release akka-persistence-sql-async which depends on akka 2.5.
https://github.com/okumin/akka-persistence-sql-async/releases/tag/v0.5.0


Use warn_once! macro from external lib

Issue #63.

Thank for the PR!
Can you check if this also fix this? I believe this was a Clippy lint warning that got triggered by the previous code, but as the implementation changed, it may not be relevant any more.

Not sure I'm getting what was the issue here. Was there a compiler warning caused by the macro wanr_once! that should not happen anymore with the macro from log-once ?

Not sure I'm getting what was the issue here.

Clippy is an additional collection of lints (static analysis) that one can opt-in to use with rust project. One of these lint was sending a warning on this code.
You can install clippy using:
rustup toolchain add nightly
cargo +nightly install clippy

And run it on the code using:
cd path/to/lumol
cargo +nightly clippy

Was there a compiler warning caused by the macro warn_once! that should not happen anymore with the macro from log-once ?

It could have been, but I actually still get it:
$ cargo +nightly clippy
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading log-once v0.1.0
   Compiling lazy_static v0.2.2
   Compiling log v0.3.6
   Compiling matrixmultiply v0.1.13
   Compiling bitflags v0.7.0
   Compiling rawpointer v0.1.0
   Compiling gcc v0.3.41
   Compiling either v1.0.2
   Compiling libc v0.2.18
   Compiling num-traits v0.1.36
   Compiling ndarray v0.6.10
   Compiling itertools v0.5.8
   Compiling log-once v0.1.0
   Compiling rand v0.3.15
   Compiling special v0.7.3
   Compiling num-complex v0.1.35
   Compiling cmake v0.1.20
   Compiling chemfiles-sys v0.6.0
   Compiling chemfiles v0.6.1
   Compiling lumol-core v0.1.0 (file:///.../lumol/src/core)
warning: useless use of `format!`, #[warn(useless_format)] on by default
   --> src/sim/mc/moves/rotate.rs:123:17
    |
123 |                   warn_once!(
    |  _________________^ starting here...
124 | |                     "Tried to increase the maximum amplitude for rotations to more than 180°."
125 | |                 );
    | |__________________^ ...ending here
    |
    = help: for further information visit https://github.com/Manishearth/rust-clippy/wiki#useless_format
    = note: this error originates in a macro outside of the current crate

    Finished dev [unoptimized + debuginfo] target(s) in 18.12 secs

Thanks ! I actually get a ton of warnings doing that, how come you don't have them ?

Because I am running cargo clippy from src/core. There are a lot of clippy lint, as we use a specific configuration for it here. But this configuration is limited to the lumol_crate, as there is no way to setup the lint level in a global configuration file for clippy yet. So we get quite a lot of warnings in the others files, mainly the tests and examples.

OK my bad, I have the same output then, I reverted the commit.
Is there a reason why the clippy lint is not run on Travis ?

Is there a reason why the clippy lint is not run on Travis?

No special reason, except that we do not want to impose to much pressure on potential contributors about external tools that are needed locally. But this can change, given we are sure that we want that. Currently, I am running clippy on the code every months or two, which was OK for now.


Virtual Scroll with Reactive Forms - FormArray

Hi,
thanks for the module. I have a question:

does virtual-scroll work with a large Reactive Form with a Form Array?

Because index changes with virtual-scroll and whilst typing, my values appear in multiple input's instead of 1.

             <virtual-scroll [items]="myRides.controls" (update)="viewPortItems = $event" #scroll [parentScroll]="scroll.window" [childHeight]="71">

+1

is there an update on this? :)  and is it possible to have dynamic height on items? Because of validation messages per formGroup in the formArray.

I've merged the PR (& modified it a bit). This issue should be working better now (not 100% perfect, but hopefully good enough). It's published to NPM (behind a flag documented in the readme). Could you try it out & close this issue if it's now resolved? Thanks.
I'm not certain if your issue was related to different-sized child items or not, so maybe that PR is unrelated. If so, maybe you can clarify your issue or create a stackblitz?

Closing this since I haven't received a response from the original poster. Please re-open if you continue to experience this issue.