[TI-4051] - Security updates - update solsson JDK image and prometheus/jmx_exporter version

`extwki@TU00444:prometheus-jmx-exporter $ docker scan trackunit/solsson-kafka-prometheus-jmx-exporter:1.0.0.TU
Testing trackunit/solsson-kafka-prometheus-jmx-exporter:1.0.0.TU...
✗ Low severity vulnerability found in sqlite3/libsqlite3-0
Description: CVE-2020-9991
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-SQLITE3-1070680
Introduced through<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in sqlite3/libsqlite3-0
Description: Information Exposure
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-SQLITE3-1070691
Introduced through<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in sqlite3/libsqlite3-0
Description: Out-of-bounds Read
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-SQLITE3-1570090
Introduced through<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in shadow/passwd
Description: Time-of-check Time-of-use (TOCTOU)
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-SHADOW-577863
Introduced through: shadow/passwd@1:4.8.1-1ubuntu<IP_ADDRESS><EMAIL_ADDRESS>shadow/login@1:4.8.1-1ubuntu<IP_ADDRESS><EMAIL_ADDRESS>From: shadow/passwd@1:4.8.1-1ubuntu<IP_ADDRESS>
From<EMAIL_ADDRESS>> shadow/passwd@1:4.8.1-1ubuntu<IP_ADDRESS>
From: shadow/login@1:4.8.1-1ubuntu<IP_ADDRESS>
and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in python3.8/libpython3.8-stdlib
Description: HTTP Request Smuggling
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-PYTHON38-1075582
Introduced through<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>and 4 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in pcre3/libpcre3
Description: Uncontrolled Recursion
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-PCRE3-580031
Introduced through: pcre3/libpcre3@2:8.39-12build1<EMAIL_ADDRESS>From: pcre3/libpcre3@2:8.39-12build1
From<EMAIL_ADDRESS>> pcre3/libpcre3@2:8.39-12build1
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in pcre3/libpcre3
Description: Out-of-bounds Read
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-PCRE3-581164
Introduced through: pcre3/libpcre3@2:8.39-12build1<EMAIL_ADDRESS>From: pcre3/libpcre3@2:8.39-12build1
From<EMAIL_ADDRESS>> pcre3/libpcre3@2:8.39-12build1
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in pcre3/libpcre3
Description: Integer Overflow or Wraparound
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-PCRE3-583594
Introduced through: pcre3/libpcre3@2:8.39-12build1<EMAIL_ADDRESS>From: pcre3/libpcre3@2:8.39-12build1
From<EMAIL_ADDRESS>> pcre3/libpcre3@2:8.39-12build1
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in libtasn1-6
Description: CVE-2018-1000654
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-LIBTASN16-578037
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in libsepol/libsepol1
Description: Use After Free
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-LIBSEPOL-1315883
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>> shadow/passwd@1:4.8.1-1ubuntu<IP_ADDRESS> ><EMAIL_ADDRESS>><EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in libsepol/libsepol1
Description: Out-of-bounds Read
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-LIBSEPOL-1315888
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>> shadow/passwd@1:4.8.1-1ubuntu<IP_ADDRESS> ><EMAIL_ADDRESS>><EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in libsepol/libsepol1
Description: Use After Free
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-LIBSEPOL-1315894
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>> shadow/passwd@1:4.8.1-1ubuntu<IP_ADDRESS> ><EMAIL_ADDRESS>><EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in libsepol/libsepol1
Description: Use After Free
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-LIBSEPOL-1315896
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>> shadow/passwd@1:4.8.1-1ubuntu<IP_ADDRESS> ><EMAIL_ADDRESS>><EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in gmp/libgmp10
Description: Integer Overflow or Wraparound
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GMP-1921284
Introduced through: gmp/libgmp10@2:6.2.0+dfsg-4<EMAIL_ADDRESS>From: gmp/libgmp10@2:6.2.0+dfsg-4
From<EMAIL_ADDRESS>><EMAIL_ADDRESS>> gmp/libgmp10@2:6.2.0+dfsg-4
From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>> gmp/libgmp10@2:6.2.0+dfsg-4
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in glibc/libc-bin
Description: Reachable Assertion
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GLIBC-1048386
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>meta-common-packages@meta
From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in glibc/libc-bin
Description: Loop with Unreachable Exit Condition ('Infinite Loop')
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GLIBC-1055780
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>meta-common-packages@meta
From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in glibc/libc-bin
Description: Out-of-bounds Read
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GLIBC-1055790
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>meta-common-packages@meta
From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in glibc/libc-bin
Description: Reachable Assertion
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GLIBC-1122573
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>meta-common-packages@meta
From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in glibc/libc-bin
Description: Double Free
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GLIBC-1123084
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>meta-common-packages@meta
From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in glibc/libc-bin
Description: Use After Free
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GLIBC-1297554
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>meta-common-packages@meta
From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in glibc/libc-bin
Description: Integer Overflow or Wraparound
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GLIBC-1315365
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>meta-common-packages@meta
From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in glibc/libc-bin
Description: Buffer Overflow
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GLIBC-2356799
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>meta-common-packages@meta
From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in glibc/libc-bin
Description: Buffer Overflow
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GLIBC-2356852
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>meta-common-packages@meta
From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in glibc/libc-bin
Description: Improper Input Validation
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GLIBC-576349
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>meta-common-packages@meta
From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in glibc/libc-bin
Description: Integer Underflow
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GLIBC-576428
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>meta-common-packages@meta
From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in coreutils
Description: Improper Input Validation
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-COREUTILS-583876
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
✗ Low severity vulnerability found in bash
Description: Improper Check for Dropped Privileges
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-BASH-581100
Introduced through<EMAIL_ADDRESS>From<EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
✗ Medium severity vulnerability found in util-linux/libblkid1
Description: CVE-2021-3996
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-UTILLINUX-2387723
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>and 24 more...
Image layer: Introduced by your base image (ubuntu:20.04)
Fixed in: 2.34-0.1ubuntu9.3
✗ Medium severity vulnerability found in util-linux/libblkid1
Description: CVE-2021-3995
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-UTILLINUX-2387728
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>and 24 more...
Image layer: Introduced by your base image (ubuntu:20.04)
Fixed in: 2.34-0.1ubuntu9.3
✗ Medium severity vulnerability found in systemd/libsystemd0
Description: CVE-2021-3997
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-SYSTEMD-2332040
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>procps/libprocps8@2:3.3.16-1ubuntu2.3, util-linux/bsdutils@1:2.34-0.1ubuntu9.1<EMAIL_ADDRESS><EMAIL_ADDRESS>From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From: procps/libprocps8@2:3.3.16-1ubuntu2.3 ><EMAIL_ADDRESS>and 6 more...
Image layer: Introduced by your base image (ubuntu:20.04)
Fixed in: 245.4-4ubuntu3.15
✗ Medium severity vulnerability found in sqlite3/libsqlite3-0
Description: Out-of-bounds Read
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-SQLITE3-581593
Introduced through<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
✗ Medium severity vulnerability found in python3.8/libpython3.8-stdlib
Description: CVE-2021-4189
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-PYTHON38-2329898
Introduced through<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>and 4 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Medium severity vulnerability found in perl/perl-base
Description: Improper Verification of Cryptographic Signature
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-PERL-1930907
Introduced through: meta-common-packages@meta
From: meta-common-packages@meta ><EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
✗ Medium severity vulnerability found in glibc/libc-bin
Description: NULL Pointer Dereference
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GLIBC-1564900
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>meta-common-packages@meta
From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Medium severity vulnerability found in glibc/libc-bin
Description: CVE-2021-3999
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-GLIBC-2359259
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>meta-common-packages@meta
From<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>and 1 more...
Image layer: Introduced by your base image (ubuntu:20.04)
✗ Medium severity vulnerability found in expat/libexpat1
Description: Integer Overflow or Wraparound
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-EXPAT-2359512
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
✗ Medium severity vulnerability found in expat/libexpat1
Description: Integer Overflow or Wraparound
Info: https://snyk.io/vuln/SNYK-UBUNTU2004-EXPAT-2387546
Introduced through<EMAIL_ADDRESS><EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>Image layer: Introduced by your base image (ubuntu:20.04)
Organization:      trackunit
Package manager:   deb
Project name:      docker-image|trackunit/solsson-kafka-prometheus-jmx-exporter
Docker image:      trackunit/solsson-kafka-prometheus-jmx-exporter:1.0.0.TU
Platform:          linux/amd64
Base image:        ubuntu:20.04
Licenses:          enabled
Tested 117 dependencies for known issues, found 37 issues.`


[MODEL] Add the :includes option to ActiveRecord adapter

that can be used to eager load submodels just like
you'd do with regular ActiveRecord.
This helps eliminate the N+1 problem when using
elasticsearch-model searches.
Example:
class Article < ActiveRecord::Base
  belongs_to :author

  # ...

end

Article.search(...).records(includes: [:author])

# Would be similar to using:

Article.includes(:author).where(...)

There might be implications that I'm not considering for other adapters but it works for me with ActiveRecord and all tests are green.

It definitely makes sense to nicely support the behaviour, I'm just wondering, since records is a true ActiveRecord::Relation instance, isn't it possible to just call eg. Category.search('one').records.includes(:articles).to_a -- if I work with the code in the associations example?

@karmi
You can technically call includes on records, but here's my issue:
records = Search::MapSearch.new(params).search.page(page).per(per_page).records
records.total_count
# => 740

records = Search::MapSearch.new(params).search.page(page).per(per_page).records.includes(map_items: :item)
records.total_count
# undefined method `total_count' for #<Map::ActiveRecord_Relation:0x007fd968e50878>

Actually, it's not working as I expected...
search = ES::MapSearch.new(params).search
@total_count = search.total_count # performs the ES query
@took = search.took

@maps = search.page(page).per(per_page).records
@maps = @maps.includes(:user, { map_items: :item }) # performs the ES query a second time!

The Elasticsearch query is performed twice!
I'm not sure how to get pagination, includes, and get some raw data about the query (took).

Having same issue, this PR would help a lot!

I've used this approach - but still, elasticsearch could support this feature, since approach I've used is hacky.

That seems like a pretty nice solution, well done. What I had done personally is just give up on kaminari pagination, using size and from in the ES query, and then getting the maps via the result ids, since I just needed a "Load more" type of pagination.

Hi, @karmi. Any plans to get this merged?

My apologies to all, and first of all to you, @dabit, this took too long. Thanks for pinging me!
I've added an integration test in the attached commit, and merged. I wanted to explore if we couldn't fix the more natural way of expressing the same, Category.search('one').records.includes(:articles).to_a, but I couldn't put much time into it, so let's start with merging @dabit's patch, and maybe work further in the future.
Thanks for the link to the decorator article, @donce!

@karmi no worries, this is great timing as precisely yesterday I had to patch one of my apps with this change and I did get a considerable performance boost. When there's a lot of data showing up in a page from different related models, that N+1 situation can kill you.
Thanks!

Awesome. Thanks, @karmi and @dabit.

@brianstorti, I'd like to accumulate more changes before a release to Rubygems, but if you need a release for your environment and cannot just use Git in Gemfile, I can do a release.

Actually, there has been a lot accumulated already :), so just released 0.1.9. There's some kind of weird unit test failures depending on whole test suite running or not, which I investigated for a bit, but didn't chew through it, will have a look at it later.

Was excited to find this PR, but having some issues implementing:
Gemfile
gem 'elasticsearch-rails', '~> 0.1.9'

/models/product.rb
  has_many :product_images, dependent: :destroy

controller
results = Product.search(query)
results = results.page(params[:page]).records(includes: [:product_images])

I get an argument error: wrong number of arguments (1 for 0)
Have I misunderstood how to implement this? Thanks in advance!

I don't think you need to call results if you're calling records. What about just Product.search(query).page(...).records(includes: [:product_images]).


Fix TempFile usage while temp dir was deleted in same process

This PR closes #926

Cannot make test running on CI, help is wanted. It seems they're running in parallel, I've tried to add [NonParallelizable] and [SingleThreaded] attributes with no luck

@Bykiev  There is conflict. Can you fix it?

LGTM


Fallback does not work for my use case

I am trying to have .env.local fallback to .env.development.
I tried env-cmd ./.env.local --fallback ./.env.development node src/server/index.js
but it does not work.
Is there a way to make it work?

At this time the --fallback option does not allow specifying the name of the fallback file. I am looking at revamping all of this at some point, but just need to find the time and come up with a decent implementation as well. The fall backfile must be named .env.


Moved to perl6/docker

Err, wrong repo. The right pull request is here https://github.com/perl6/perl6-docker/pull/1


Update Bower manifest

Remove deprecated "version": http://bower.io/docs/creating-packages/#version
Add "license"
Add "homepage"
Use fuzzier version requirement for angular-messages (~)

@simison Left a line comment. Otherwise looks good.

@codydaig Squashed.

LGTM!
@simison Thanks! :-D

LGTM

LGTM


Add greater functionality to progress writers.

Currently only mol.id and repr(mol) is written to the log file. The proposed change would allow the user to select what is written depending on the input file for the EA.
with open('progress.log', 'w') as logfile:
                logfile.write(
                    '\n'.join(self.log_file_content(self.progress))
                )

Part that selects what is written to log file:
 @staticmethod
    def log_file_content(progress):
        for sp in progress.subpopulations:
            for mol in sp:
                yield f'{mol.id} {mol}'
            yield '\n'

Irrelevant as of #95


Cross compilation for aarch64 report

Hi, just wanted to let you know that it's possible to cross compile for aarch64 without too much effort (I managed to do it while totally unfamiliar with rust).
What I needed to do (information gathered by googling for similar problems):

Create a Cross.toml file with the following contents (not sure if all absolutely necessary):

[build]
default-target = "aarch64-unknown-linux-gnu"
pre-build = [
    "dpkg --add-architecture $CROSS_DEB_ARCH",
    "apt-get update",
    "apt-get install -y alsa-tools libasound2-dev libdbus-1-dev pkg-config",
    "apt-get install -y alsa-tools:$CROSS_DEB_ARCH libasound2-dev:$CROSS_DEB_ARCH libdbus-1-dev:$CROSS_DEB_ARCH",
    "cp -r /usr/lib/aarch64-linux-gnu/* /usr/aarch64-linux-gnu/lib/",
]

build with:

cross build --target=aarch64-unknown-linux-gnu --release

I first wanted to build it on my raspberry pi directly but I ran out of RAM.

Never tried cross for with ytermusic so I don't know if it's expected or not. But cross uses containers so it's possible there is some (a lot) of overhead. Have you tried on a x86 computer with a lot of RAM? I can try it if you want tomorrow.

I compiled on debian x86_64 with 32 GB RAM, I think the total system memory usage did not go over around 5 GB during compilation.


Check for missing csv entries

For example, missing accession in an EMPI-Accession extraction.

I have made a python script for this
Here is the Github link to the repo: https://github.com/Nishchal-007/CheckingNull
Also, there is a dummy CSV file for testing purpose
Let me know if there's anything else to be done.

A few pointers:

When we say missing entries, what we mean is a file:

empi, accassion
32323,<PHONE_NUMBER>2
23323,
323232, 332323
,<PHONE_NUMBER>
In this case, the line 2 and 4 should be skipped, but the rest of the extraction should go on.

It is not the entire CSV that is empty or should be considered invalid and ignored. Rather, making the executions succeed, despite the missing lines.

Also, I recommend cloning the repository and submitting pull requests, rather than creating private repositories with stand-alone codes. The code changes will modify the https://github.com/Emory-HITI/Niffler/blob/dev/modules/cold-extraction/ColdDataRetriever.py (Please use the dev branch).

Okay, Will do that !!

I have forked and made changes to the cold-extraction module and added the checkCSV.py file.
Can you please check it out?

That pull request modifies 67 files. Please resubmit a new pull request without modifying other files, also addressing other comments in the pull request.

Yeah I checked the points in the pull request
My approach to this current issue is if there are any missing values in the file I'm just dropping them in the beginning itself
Is this approach okay or should I change this?

Ideally, you should drop it on the go, as otherwise, this process of reading the file will introduce an initial delay.
Also, there is no reason to create a separate python class. You can modify modules/cold-extraction/ColdDataRetriever.py.
You can use the "csv_file" variable there as it already points to the csv_file.

Made the necessary changes in the ColdDataRetriever.py file

Please pay attention to the comments.
https://github.com/Emory-HITI/Niffler/pull/115/files changes files unnecessarily. Please avoid changing files that have no relevance to the pull request. Also, I believe you are modifying only the ColdDataRetriever.py and other changes (such as a sample CSV file) are not necessary.

Only changed the ColdDataRetriever.py file

Made changes according to the specified comments.

Hey,
I made the required changes to the ColdDataRetriever.py file
Can you please check it out?

Looks good now. Merged to dev. Thanks.


Fireball spec gaining a buff from a talent that is not taken

Describe the bug
On the mage sim if you select ttw/fireball spec it is gaining clear casting procs which is normal but these procs are giving the talent arcane potency which makes your next spell have 30% increased crit chance. This talent is in deep arcane and this fireball spec doesnt not have access to it yet the sim still shows getting it every time clear casting activates.
To Reproduce
Steps to reproduce the behavior:

Go to mage sim select the fireball spec talents and then sim
Click on results tab and then on buffs
Scroll down to see arcane potency buff is there from a talent you cant get in this spec
See error

Expected behavior
not to see this buff as you cant get it
Sim Links and Screenshots
no need to link you recreate just by selecting fire talents including clear casting but not arcane potency
Desktop (please complete the following information):

OS: windows
chrome
latest

Thanks for the report! This is just a visual bug, although the aura is being applied it isn't providing any crit bonus. Will be fixed soon though.


WIP: Support remote access for TDB state codes

Description

Fixes #
Interface impacts

Testing

Unit tests

[ ] No unit tests
[ ] Mac
[ ] Linux
[ ] Windows

Independent check of unit tests by [REVIEWER NAME]

[ ] [PLATFORM]:

Functional tests

No functional testing.

Superceded by https://github.com/sot/ska_tdb/pull/19


Need help configuring ScreamReader

I've installed Scream on my Hyper-V Windows guest machine, and ScreamReader on my Windows Host both are running the latest 64-bit OS system and build. I've opened up port 4010 both inbound and outbound on both the machines and I've already configured ScreamReader to automatically start-up upon log-in.
My default device in the guest is set to Scream output and it's at 100% and my ScreamReader is as well set to 100% by default but for some reason, I can't hear any audio coming from my Windows guest machine to my Windows host machine? any idea how to go about so...?

My bad for opening this up, just going to write down what solved it. I've added in UnicastIPv4 and UnicastPort accordingly and voila I can finally hear sound from my guest windows virtual machine to my Windows host machine and works flawlessly with ScreamReader! Hopefully, it might help someone.


[MINOR][SQL] Fix typos by replacing 'much' with 'match'.

What changes were proposed in this pull request?
This PR fixes two trivial typos: 'does not much' --> 'does not match'.
How was this patch tested?
Manual.

Test build #54452 has started for PR 12042 at commit e0d5aae.

Thanks - I've merged this.

Test build #54452 has finished for PR 12042 at commit e0d5aae.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/54452/
Test PASSed.

Merged build finished. Test PASSed.


Support showing path of file in stacktraces

raven-go supports the SetIncludePaths (https://github.com/getsentry/raven-go/blob/5c24d5110e0e198d9ae16f1f3465366085001d92/client.go#L937) option to show paths of the file in stacktraces.
It would be great if sentry-go would also allow to show absolute or GOPATH relative paths to the source codefiles in the stacktrace.
This can be especially helpful when a stacktrace contains the same sourcecode filename from different packages.

IncludePaths is used to mark some of the frames in the stacktrace as coming from the app instead of 3rd party module. It doesn't modify the paths at all, see: https://github.com/getsentry/raven-go/blob/5c24d5110e0e198d9ae16f1f3465366085001d92/stacktrace.go#L176-L186

@kamilogorek thanks, you are right, SetIncludePaths seems not related.
Is there a way to show the full path the source code file in the stacktraces instead of only the filenames?

@fho we already does that. When you go to sentry-go/example/basic and run it go run main.go you'll see that the exception has all the data, including absolute path of a frame:

Is this not the case for you? Can you provide a link to an event that's missing this data?

I figured out that only the representation in the UI changed.
The full-paths are still there:
With raven-go I had full-paths in the stacktrace and no mouseover, like:

With sentry-go the full-path show up as mouse-over text in the stacktrace:

Sorry for the effort and thanks for the help!

No worries, glad you found what you needed :) Cheers!


fix: all broken readme links pointing to examples

The readme file is pointing to the root of the Github website. I changed the links to be pointing to the repository folders. It should solve the Page Not Found issue when clicking on the readme links. That's not the fanciest solution I know, but it's better than just not working at all.
It only works on the main branch, because of the markdown limitations.
fix: #15
fix: #44

The current method seems to only work on GitLab. It seems the correct way to have the Markdown work properly on GitHub would be to include the README.md in the URL. The change would be
- - [Applications](/Applications/) groups a number of examples ... .
+ - [Applications](Applications/README.md) groups a number of examples ... .

The latter would render as

Applications groups a number of examples ... .

If you could update the PR with that, that would be nice. Thanks!

I updated the PR yesterday. Should be working now!

I've messed about with using various types of redirects and I think GitHub is just broken, and we're hitting the same issue as https://github.com/orgs/community/discussions/67750.

Nice research!
I made a lot of tests and the only one that worked for me was to make absolute paths and not relative paths. I thought it was just me that did something wrong, but apparently it's not just me. First I made a PR using only absolute paths. I think it is better to have something working being hardcoded than not have anything working at all. Even though I still agree with both @chicheng and @Naraenda that the right way to do it is using relative paths.
I think we can leave this PR as it is, so the next people looking for the reason of the README links not working can understand reading this discussion.

@Naraenda irrespective of the GitHub bug, can you have a plan to fix this? Even if you have absolute links, we cannot have this project be broken any longer.

Closed with #51


Error when starting masakari-controller

Hello,
I downloaded the master branch of this project.
now I can vagrant up the controller and compute nodes.
(with some try and error but adding apt-get and pip cmd to vagrantfile fixed them).
deploy OpenStack in Controller/Compute and devstack started OK.
but when I try to start the masakari-controller it's not running
stack@controller:~ /devstack$ sudo service masakari-controller start
Starting masakari:  *
stack@controller:~ /devstack$ sudo service masakari-controller status
** masakari is not running
the only error I found in the log is:
stack@controller:~/masakari$ cat /var/log/masakari/masakari-controller.log
Feb 06 03:23:18  masakari(20458): CRITICAL: An error during initializing masakari controller: No option 'log_file' in section: 'log''
Feb 06 03:23:18  masakari(20458): ERROR: <type 'exceptions.OSError'>'
Feb 06 03:23:18  masakari(20458): ERROR: [Errno 17] File exists: '/var/log/masakari/''
Feb 06 03:23:18  masakari(20458): ERROR:   File "/opt/masakari/controller/masakari_controller.py", line 102, in init
os.makedirs(log_dir)
'
Feb 06 03:23:18  masakari(20458): ERROR:   File "/usr/lib/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
'
any idea how to fix this? Thanks.

Hi Chtwerdna,
It seems that, masakari failed to init the log file directory and create the log file.
Could you please share the [log] section of your masakari.conf file.
You may retry after completely delete the "/var/log/masakari",
DO NOT FORGET to backup the previous log files before delete it.
And, if you have no strong reason to use this older version of Masakari,
I strongly recommend you to move to latest version of  Masakari in Openstack.

Hi sampathP,
Thanks for the hint.
the [log] section in my /etc/masakari/masakari-controller.conf only has one line.
[log]
log_level = info
After googling I found masakari has a sample file for this conf.
https://github.com/ntt-sic/masakari/blob/master/masakari-controller/etc/masakari-controller.conf.sample
(there is also a sample file in the directory: /etc/masakari/masakari-controller.conf.sample )
is these two file I found the missing configurations.
After adding the following two lines, the controller starts normally.
log_file = /var/log/masakari/masakari-controller.log
logging_context_format_string = %(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [%(threadName)s] %(message)s
By the way, I know that there's a latest version of masakari, but I'm using OpenStack mikata.
Also this is the first try to verify the function and behaviors so I just need a quick setup environment.
After this I may try the new masakari in Openstack.
Thanks again for both the hint and the recommendation.

Hi Chtwerdna,
As you found out, with log settings, this should work fine.
Even in openstack masakari, masakari-monitors and python-masakariclient,
you can find the samples of required config file and you can generate the full config file with tox.
Let us know if you need any help..


Add query and iterations connector, pr processor and standard plugin files

Implement [sc-92873]

New repo was created https://github.com/dataiku/dss-plugin-shortcut so closing this PR


Use rust 1.8.0 for testing

tempfile, which is a dependency for gag, requires cargo 0.9.0 (released with rust 1.8.0) at least.

Thanks!


Create a sample showing how you can get around the output limit of various LLMs

We will create a sample showing how you can get around the output limit of LLMs through Amazon Bedrock through creative prompting. In our sample we will leverage Claude 3, but a similar strategy can be used with alternative LLMs.

+1 - One big issues with now is the "20 Image Per API Call Max" that Claude3 has. It makes it challenging to do analysis/summary of long PDFs and docs longer than 20 pages.

@dbavro19 Would you want to take this on since you already have a code sample for it?

@dbavro19 - do you have any Sample Code for this? Let me know if I can help wrap this one up.


Have an automatic PR with updated generated code for each generator release

Done in C# already, when I trigger a release of autorest.python, I want an auto-PR here with the regeneration of all track2 that uses autorest.
It's done in C# already

This has been semi-finished. Currently it is an opt-in service and being piloted with App Configuration. After testing, onboarding more services, and documenting the capabilities this issue can be closed

Here is my original PR: https://github.com/Azure/azure-sdk-for-python/pull/16667

Let's close for now and revisit as necessary


ERROR  Error: Objects are not valid as a React child (found: object with keys {id, skillName}). If you meant to render a collection of children, use an array instead.

ERROR  Error: Objects are not valid as a React child (found: object with keys {id, skillName}). If you meant to render a collection of children, use an array instead.

  let newArray = response.data.data.map((item) => {
      return {key: item.id, value: item.skillName}
    })
    setAPIDataSkils(newArray);

  let newArray = response.data.data.map((item) => {
      return {key: item.id, value: item.skillName}
    })
    setAPIDataSkils(newArray);


Make Ping JSON-RPC result human readable

Return JSON Value from Pong ssz bytes on json-rpc portal_*Ping requests and update tests.
Fixes https://github.com/ethereum/trin/issues/198

Looks like camelCase here is according to the JSON-RPC spec

Yeah, we decided to go with this route mainly because of this guide: https://google.github.io/styleguide/jsoncstyleguide.xml.


Detect does not work with dynamic mail and stream

	--with-stream=dynamic \
	--with-stream_ssl_module \
	--with-stream_ssl_preread_module \
	--with-stream_geoip_module=dynamic \
	--with-mail=dynamic \
	--with-mail_ssl_module \

It builds only ct

should be fixed by d7049bfd1c6cbefa76432b2676dc65ed3ac74f31


Race condition when mounting RBD static PVs with the same image name in different pools

Describe the bug
When two RBD Images with the same name in different pools are attempted to be mounted as staticVolume following this procedure, only the one attempted to be mounted first will succeed.
The later one succeeds in creating the PV/PVC and associating the pod with the PVC, but the pod remains in the Pending state with the following error displayed in the events in the pod:
Multi-Attach error for volume "foo-pv" Volume is already used by 1 pod(s) in different namespaces

Environment details

Image/version of Ceph CSI driver : v3.10.2
Kernel version : 6.5.0-26-generic
Mounter used for mounting PVC : rbd
Kubernetes cluster version : v1.29.3
Ceph cluster version : 18.2.1 reef (stable)

Steps to reproduce
Steps to reproduce the behavior:

Setup details:

Setup Rook-ceph Cluster
Create pools named foo and bar, enabled application rbd
Create RBD Image test under each 2 pools

Deploy below 2 PVsapiVersion: v1
kind: PersistentVolume
metadata:
  name: foo-pv
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 1Gi
  csi:
    driver: rook-ceph.rbd.csi.ceph.com
    fsType: ext4
    nodeStageSecretRef:
      name: rook-csi-rbd-node
      namespace: rook-ceph
    volumeAttributes:
      clusterID: "rook-ceph"
      pool: "foo"
      staticVolume: "true"
      imageFeatures: "layering,fast-diff,object-map,deep-flatten,exclusive-lock"
    volumeHandle: test
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: bar-pv
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 1Gi
  csi:
    driver: rook-ceph.rbd.csi.ceph.com
    fsType: ext4
    nodeStageSecretRef:
      name: rook-csi-rbd-node
      namespace: rook-ceph
    volumeAttributes:
      clusterID: "rook-ceph"
      pool: "bar"
      staticVolume: "true"
      imageFeatures: "layering,fast-diff,object-map,deep-flatten,exclusive-lock"
    volumeHandle: test
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem

Claim above 2 PVs from some pods placed in different namespaces.
See errorMulti-Attach error for volume "foo-pv" Volume is already used by 1 pod(s) in different namespaces

orMulti-Attach error for volume "bar-pv" Volume is already used by 1 pod(s) in different namespaces

Actual results
Later mounted pods will stack at Pending due to an error.
Expected behavior
Both pods successfully mount the RBD.
Logs
If the issue is in PVC mounting please attach complete logs of below containers.

csi-rbdplugin
No logs are apeeared
driver-registrarI0331 07:32:36.733019  899351 main.go:135] Version: v2.10.0
I0331 07:32:36.733206  899351 main.go:136] Running node-driver-registrar in mode=
I0331 07:32:43.746178  899351 node_register.go:55] Starting Registration Server at: /registration/rook-ceph.rbd.csi.ceph.com-reg.sock
I0331 07:32:43.746370  899351 node_register.go:64] Registration Server started at: /registration/rook-ceph.rbd.csi.ceph.com-reg.sock
I0331 07:32:43.747289  899351 node_register.go:88] Skipping HTTP server because endpoint is set to: ""
I0331 07:32:44.681946  899351 main.go:90] Received GetInfo call: &InfoRequest{}
I0331 07:32:48.988262  899351 main.go:101] Received NotifyRegistrationStatus call: &RegistrationStatus{PluginRegistered:true,Error:,}

Additional context
I used Rook ceph, but I don't think the problem is related to Rook.

@AsPulse i believe the error is coming from the kubernetes please check kubelet logs. is it possible to use different names in volumeHandle in the PV?


Consider having a transformer being influenced by the context

The case reported by @loradd is this: I have an expression that I may want to translate differently depending on where it is contained. Currently I can specify only one way to perform the transformation

Let's postpone it to when we will have more feedback


Markdown editor doesn't save cursor location on focus / de-focus

Just something annoying that I noticed dogfooding.  It's always back at the start. I confirmed that Jupyter keeps the cursor position in this scenario.

Thanks for your feedback. This issue will likely be addressed once VS Code adds native support for editing notebooks. Please see https://github.com/microsoft/vscode/issues/91987.


Test musedev docker

Scripts to test the fixr api in the musedev docker container.

@ftc can you test the finalize method?
A test case is the following, you can use it with docker as you are calling the "version" endpoint:
$ BASEPATH=`pwd`/test/data && sed "s:REPOPATH:${BASEPATH}:" test/data/finalize_input.json  | ./biggroumcheck.sh /Users/sergiomover/works/projects/muse/repos/biggroum/python/fixrgraph/musedev/test/data 04f68b69a6f9fa254661b481a757fa1c834b52e1 finalize

You need to unzip the AwesomeApp.zip file in /Users/sergiomover/works/projects/muse/repos/biggroum/python/fixrgraph/musedev/test/data before (add this step to the test script).
You need to run the search service to make it work.

Build the docker image for the search service in https://github.com/cuplv/FixrGraphPatternSearch/tree/develop/docker_search (follow the README.md instruction, just build the image)
Build the docker image for the source code service https://github.com/cuplv/fixr_source_code_service/tree/master/docker (follow the README.md instruction, just build the image)
Use the docker compose file in https://github.com/cuplv/biggroum/tree/develop/docker_compose.
Generate the docker compose:

python get_docker_compose.py

Run the services:
# docker-compose up

The other issue is to reach the search service from the musedev docker container.
You can either play with the docker compose file or running the musedev docker container telling how to reach the host system (never done that but it should be possible https://forums.docker.com/t/accessing-host-machine-from-within-docker-container/14248/11)

The changes to the biggroumscript.sh breaks the test in python/fixrgraph/musedev/test.
We were testing that the bash script was calling the python script correctly, but now the bash script became "path dependent" (e.g., /root/biggroumsetup) and without a way to skip the setup process (use of absolute file instead of environment variable to specify if we have to do the installation step or not).

@ftc  can you take a look at the readme file explaining how to test the API: https://github.com/cuplv/biggroum/blob/test_musedev_docker/python/fixrgraph/musedev/README.md
There are some TODOs to be completed there (ignore the one about configuring the .muse.tml file).
The others are:
missing address for the search server
missing test cases (for talk and reaction --- look at the python ones to get the input/output)
missing commands to manually run the container


OpenXR basic game not working standalone and in the Quest 2 in Godot 4

Godot version
4.0-beta13
System information
ArchLinux Latest, GTX 1060 6 GB VRAM, 64 GB RAM, i7 6th gen
Issue description
When I make a basic XR game (using the reference from documentation) that throws that error when I run standalone:

And when I run it in Quest 2 the screen gets entirely black with a three-point loading animation.
Meta Quest 2 (developer mode enabled) is not recognized in this version of Godot 4 and I can run over Quest 2 using directly Godot.
Steps to reproduce

Download the project made with Godot 4 beta 13
Press the "play" button
It must throw a "That version of Vulkan is not supported" error
Export to Android
Upload it by using sidequest
Try the game
It must show a black screen

Minimal reproduction project
That is the project I made:
OpenXRTest.zip

This is the console output when I launch standalone:
[alexiarc@digitecnology ~]$ godot4
Godot Engine v4.0.beta13.official.caacade56 - https://godotengine.org
OpenGL Renderer: NVIDIA GeForce GTX 1060/PCIe/SSE2

Editing project: /data/user/alexiarc/documents/godot-projects/OpenXRTest
Godot Engine v4.0.beta13.official.caacade56 - https://godotengine.org
Vulkan API 1.3.224 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1060
[alexiarc@digitecnology ~]$
Running: /usr/bin/godot4 --path /data/user/alexiarc/documents/godot-projects/OpenXRTest --remote-debug tcp://<IP_ADDRESS>:6007 --editor-pid 402611 --position 4224,216 res://Main.tscn
Godot Engine v4.0.beta13.official.caacade56 - https://godotengine.org
Error [GENERAL |  | OpenXR-Loader] : RuntimeManifestFile::FindManifestFiles - failed to determine active runtime file path for this environment
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : RuntimeInterface::LoadRuntimes - unknown error
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : RuntimeInterface::LoadRuntimes - failed to load a runtime
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : Failed to find default runtime with RuntimeInterface::LoadRuntime()
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : Failed querying extension properties
ERROR: OpenXR: Failed to enumerate number of extension properties
   at: load_supported_extensions (modules/openxr/openxr_api.cpp:174)
ERROR: Parameter "OpenXRAPI::get_singleton()" is null.
   at: check_graphics_api_support (modules/openxr/extensions/openxr_vulkan_extension.cpp:69)
ERROR: Could not initialize Vulkan
   at: DisplayServerX11 (platform/linuxbsd/x11/display_server_x11.cpp:5043)

If I set the current XR Runtime in SteamVR (SteamVR current XR runtime) it works in desktop through ALVR.

There is the video of ALVR desktop app working through communicating with the Quest 2:
https://user-images.githubusercontent.com/18708610/213640237-facd96a9-de35-4c6e-b6d0-2dc6ed092b08.mp4
But in Quest 2 as an apk it doesn't work. It appears on a black screen.

I watched this tutorial and modified the godotopenxrmeta/src/main/AndroidManifest.xml of the Meta plugin from:
<meta-data
            android:name="com.oculus.supportedDevices"
            android:value="quest|quest2|questpro" />

To:
<meta-data
            android:name="com.oculus.supportedDevices"
            android:value="all" />

And compiled and used these plugin: https://github.com/GodotVR/godot_openxr_loaders
This is the video of the app working now:
https://user-images.githubusercontent.com/18708610/213647799-728ff9d9-f710-4828-96f4-c5cc58835509.mp4

The issue on desktop is likely caused by the regression issue we found in beta 13 and should be fixed by #71450
Exporting to Quest is indeed the issue with the manifest file, we're currently discussing how best to approach that one. Manually editing the manifest file is indeed the way to approach this for now.

This should be retested on the official release with installing the latest loaders plugin.

@Alexia-AT-Digitecnology can you confirm your issues is fixed and close this issue if so.
The stable release of Godot 4 is working fine with the Quest but I don't have the ability to test a Linux setup.

I can't get the latest official 4.0 release to work with OpenXR at all while using Linux (my only development platform). I installed the "Godot XR Android OpenXR Loaders" plugin, but no OpenXR plugin appears in the Plugins tab for my project. There is also no export icon for the Quest in the IDE like there is in the 3.x series. When I export the project, then load the program onto my Quest 2 using SideQuest and run it from Unknown Sources, I get:

"OpenXR was requested but failed to start.
Please check if your HMD is connected.
When using Windows MR please note that WMR only has DirectX support, make sure SteamVR is your default OpenXR runtime.
Godot will start in normal mode."

I don't remember how I got the Quest 2 and 3 to work, but all the Quest-related issues in my prior reply have been resolved. I still have issues with OpenXR and the Quests, but I'm not going to pollute this issue with them.

Just in case someone finds it useful:
So I was running in circles on this issue on Quest 1. I kept getting the "OpenXR was requested but failed to start.". Now I kind of resolved it only to run into a crash issue instead.
The solution to get to this point was kind of "obvious". In the export dialogue (or in export_presets.cfg) there are a number of new toggles that need to be set for it to work on Quest 1. This was added in this change.
These toggles are (I think):
xr_features/enable_meta_plugin=true
meta_xr_features/quest_1_support=true
And maybe:
plugins/GodotOpenXRMeta=true
Now at least I'm not getting the error message but I'm getting a crash with no info instead. Not sure how I can get an error log. I will look into that later.
(I also found some mention about eye tracking crash s I tried toggling meta_xr_features/eye_tracking=1 but it didn't seem to have any effect.)


Wikilinks with # do not work

A link to [[A#B]] renders as w2wiki.org/index.php/A#B, and is eventually written to a file called "A".

My w2wiki fork has this capability; it was added with this commit.


Getting the same output for the intel realsense camera

Hi,
I tried to run this demo in my Jetson. https://www.jetson-ai-lab.com/tutorial_live-llava.html
After analyzing a few frames, I keep getting the same results over and over again even though the camera is seeing different scenes. I suspect that the model gets the same frame as input after a while.
Thanks so much for helping.

+++


Performance on Large Language Models with Fewer Parameters

hi, nice work~
I'm quite interested in the performance of this approach on large language models with fewer parameters, such as using three 7B models as a proposer and a 14B model as an aggregator, and so on. Have you made any attempts in this direction?

We had some experiments for stuff like this in the early stage of the project. We saw some gains but the performance highly depend on which model is the aggregator. Smaller models tend to be less capable at aggregation. Some smaller models even decrease performance. The models we used were very different from the strong small models we are seeing now of course, so results may be very different with gemma-2, llama 3.1 8b etc.

thanks


Use CSV data source to read unloaded data from Redshift

This patch refactors this library's read path to use Spark 2.0's built-in CSV data source to read unloaded Redshift output from S3. This approach has a few advantages over our existing custom-InputFormat-based code:

It will benefit from performance improvements in FileScanRDD and HadoopFsRelation, including automatic coalescing.
The Univocity CSV parser is likely to be faster than our old custom code.
We don't have to create a separate RDD per partition and union them together, making the RDD DAG smaller.

In order to do this, I had to change the UNLOAD command to add the ADDQUOTES option. Previously, the unloaded data used | as a delimiter and used \| to escape that delimiter, but it appears that Spark's CSV data source isn't able to handle non-quoted escaping of delimiters (@falaki, could you confirm?). I believe that this should be safe, but it would be great to figure out why this library didn't take this approach in the first place. @jaley, do you know of any gotchas in doing this?

Put the newline issue aside, if we get this merged, we should be able to remove RedshiftInputFormat, right?

Yes, in principle we could remove RedshiftInputFormat. I think that it's technically a public API in the sense that it's mentioned offhand in the README, but it's really hard to use and I doubt that users of that InputFormat are also using the more full-fledged functionality of this library as part of the same project. Therefore I'd be fine with removing it, especially if this version will become 3.0.0. I might take care of that in a separate patch, though.

Regarding newlines, I think that our use of the ESCAPE unload option should take care of this. From the Redshift UNLOAD docs:

ESCAPE
For CHAR and VARCHAR columns in delimited unload files, an escape character () is placed before every occurrence of the following characters:

Linefeed: \n
Carriage return: \r
The delimiter character specified for the unloaded data.
The escape character: \
A quote character: " or ' (if both ESCAPE and ADDQUOTES are specified in the UNLOAD command).

Univocity's default behavior is to process escapes and expand them. It's probably a good idea to add some more end-to-end tests with this, though: I can add some tests to RedshiftReadSuite which write strings containing all of these special characters to Redshift and try to read them back as part of the same unload.

Just checked with @mengxr, since Redshift already supports Avro now, users should be able to workaround the newline issue (if it still exists now) by switching to Avro. Since we are about to bumping the version to 3.0.0, I think it's fine.

@JoshRosen When UNLOAD, redshift literally put a \ before a newline character if it exists in the record, not replacing newline by \n. This leads to multi-line records, which were not supported by CSV source, at least at the time I wrote this input format. If I remember correctly, ADDQUOTES still leaves newline chars as is.
There is a test for this at https://github.com/databricks/spark-redshift/blob/master/src/test/scala/com/databricks/spark/redshift/RedshiftInputFormatSuite.scala#L69. You can check whether CSV source can load that dataset correctly.
If CSV source can handle those multi-line records correctly, we should remove the input format.

Let me check tomorrow.  Even if we can't use the CSV reader I think we'll still be able to refactor to use HadoopFSRelation with a custom FileFormat

@mengxr, I just tested this and you're right: Redshift is just prepending \ rather than replacing the original characters with escapes. However, this appeared to work by accident for small input files because the Univocity parser supports multi-line records by default. It looks like Univocity has a recordEndsOnNewline option which can be set to enforce that requirement, which would help to guard against cases where multi-line records appear to work but will break as soon as files get large enough to be split.
@marmbrus, @falaki, @mengxr, do you think that we should enable recordEndsOnNewline to prevent users from writing code which works by accident on small files but fails in a large data environment? This risks breaking users' local programs which are just using Spark as a convenient programming API for small data, but could help to avoid user confusion. Probably fine to leave it as-is but we might want to add a warning to the open-source documentation.

I'd still like to use a FileFormat-based DataSource since that will handle auto-coalescing, so I'm going to close this PR and will open a new one which replaces the CSV usage with a custom format (which can hopefully be a thin harness wrapping the InputFormat).

I would probably put a warning, rather than change the behavior.

Even Univocity supports multi-line records, we still need to keep the special logic to seek for the start position in a file split to avoid partial records near the split boundary. See https://github.com/databricks/spark-redshift/blob/master/src/main/scala/com/databricks/spark/redshift/RedshiftInputFormat.scala#L168.


extract operator: add support for week keywords

close #435

Test with datafusion!
un  --bin datafusion-cli
   Compiling sqlparser v0.15.0 (/Users/yangjiang/CLionProjects/sqlparser-rs)
   Compiling datafusion-common v7.0.0 (/Users/yangjiang/CLionProjects/arrow-datafusion/datafusion-common)
   Compiling datafusion-expr v7.0.0 (/Users/yangjiang/CLionProjects/arrow-datafusion/datafusion-expr)
   Compiling datafusion-physical-expr v7.0.0 (/Users/yangjiang/CLionProjects/arrow-datafusion/datafusion-physical-expr)
   Compiling datafusion v7.0.0 (/Users/yangjiang/CLionProjects/arrow-datafusion/datafusion)
   Compiling datafusion-cli v7.0.0 (/Users/yangjiang/CLionProjects/arrow-datafusion/datafusion-cli)
    Finished dev [unoptimized + debuginfo] target(s) in 42.48s
     Running `target/debug/datafusion-cli`

DataFusion CLI v7.0.0
❯ select EXTRACT(WEEK FROM to_timestamp('2020-09-08T12:00:00+00:00'));
+-----------------------------------------------------------------------+
| datepart(Utf8("WEEK"),totimestamp(Utf8("2020-09-08T12:00:00+00:00"))) |
+-----------------------------------------------------------------------+
| 37                                                                    |
+-----------------------------------------------------------------------+
1 row in set. Query took 0.005 seconds.
❯

@alamb PTAL

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 3 (66.67%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.009%) to 90.44%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/parser.rs
1
2
50.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.009%

Covered Lines:
7275

Relevant Lines:
8044

💛  - Coveralls

Thanks @Ted-Jiang  @liukun4515 and @houqp


Enables shuffling in iterative_train_test_split

Moving the PR (https://github.com/scikit-multilearn/scikit-multilearn/pull/290) made by @erikhuck in scikit-multilearn.

Hello @mbbyn! Can you please specify in greater detail what you ment with the comment (here https://github.com/scikit-multilearn/scikit-multilearn/pull/290#issuecomment-1872280469)? I added the following change in order to address it: https://github.com/scikit-multilearn-ng/scikit-multilearn-ng/pull/8/files#diff-ce9a65da687b67daef369761039bc521468402ca622ba166f038bd699bbb76a5R104

Hello @northern-64bit 👋
If you notice, the iterative_train_test_split function simply instantiates the IterativeStratification class under the hood and passes it the shuffle and random_state arguments.
The PR in question is fixing the lack of shuffling in the function, but a better fix IMO would be to update the class instead. This way, people using the IterativeStratification class would also get the shuffle fix (which doesn't exist in the class yet).
For example, please see how the main scikit-learn library uses the shuffle in the class itself (although I think they should also use random_state as well for reproducible results).
https://github.com/scikit-learn/scikit-learn/blob/678e3999eeaadcaaef523d1d0d2f52a25986d460/sklearn/model_selection/_split.py#L764-L765

Hello @mbbyn!
Thanks for the more detailed explanation! I have now moved the changes to IterativeStratification in _iter_test_indices, which is accessed every time .split() is used. So it should now work for all uses of IterativeStratification.


How to preserve image style?

This is printed delta to Json representation and html conversion result:

@raimkulovr I think the problem is that you have a style attribute with a string of "width: ...; height: ...;". According to this: https://quilljs.com/docs/guides/designing-the-delta-format#embedded-content, only a direct width attribute is supported (there is no style attribute since that is CSS, not Quill Delta), so your delta should look like something like:
[
//...
          {
            "insert": {"image": "http://yahoo.com/abc.jpg"},
            "attributes": {"width": 100}
          },
 //...
]

Where width is a direct attribute, and there is no style attribute.
I've updated the image tests to test this, and it seems to work:
      test('should render image and image links', () {
        final ops = [
          {
            'insert': {'image': 'http://yahoo.com/abc.jpg'}
          },
          {
            'insert': {'image': 'http://yahoo.com/def.jpg'},
            'attributes': {'link': 'http://aha'},
          },
          {
            'insert': {'image': 'http://yahoo.com/abc.jpg'},
            'attributes': {'width': 100},
          },
        ];
        final qdc = QuillDeltaToHtmlConverter(ops);
        final html = qdc.convert();
        expect(
            html,
            '
'
            ''
            ''
            ''
            ''
            ''
            '
');
      });

Got it, thank you! I'm adding images via flutter_quill_extensions, so it's unfortunate to learn that they are using an improper format.


Fix example project's link

cc @AlecStrong

Why don't we just link to the repo?

i believe it was so that the linked directory had the gradle file which applied this plugin directly

Yeah that makes sense. But it should be fairly easy to discover based on the folder name. Plus few others link to anything but the enclosing repo.

README.md is generated. Could you please edit src/docs/examples.md, regenerate readme with documentr task and push both files? Thanks

Done.


deisctl start platform hangs at deis-store-monitor.service: activating/start-pre

I've installed deis v1.6.1 on to my MacBook Pro (2.2 GHz Intel Core i7, 16 GB 1333 MHz DDR3) and followed the instructions for using vagrant. When I run deisctl start platform on an otherwise idle system, deisctl stops at deis-store-monitor.service: activating/start-pre for close to 30 minutes before moving on to deis-store-monitor.service: active/running.
Thinking that giving the virtual machines more CPUs might help the situation, I made the following modifications to Vagrantfile
$ diff --git a/Vagrantfile b/Vagrantfile
index c0d9dad..becab9d 100644
--- a/Vagrantfile
+++ b/Vagrantfile
@@ -20,7 +20,7 @@ $enable_serial_logging = false
 $share_home = false
 $vm_gui = false
 $vm_memory = 2048
-$vm_cpus = 1
+$vm_cpus = 3
 $shared_folders = {}
 $forwarded_ports = {}

@@ -106,6 +106,7 @@ Vagrant.configure("2") do |config|
         config.vm.provider :virtualbox do |vb, override|
           vb.customize ["modifyvm", :id, "--uart1", "0x3F8", "4"]
           vb.customize ["modifyvm", :id, "--uartmode1", serialFile]
+          vb.customize ["modifyvm", :id, "--cpuexecutioncap", "100"]
         end
       end

But this didn't help speeding up the process at all.
uptime on deis-01 shows 01:44:27 up 39 min,  1 user,  load average: 0.34, 0.35, 0.27 and I don't see any errors in journalctl -u fleet or journalctl -u etcd.  Similar numbers are seen on deis-02 and deis-03.
It now has been almost an hour and the deisctl start platform has not finished running.
Is the performance I am seeing running deisctl start platform normal for this age hardware?  (In other words, is it time to purchase a new Macbook Pro?)
System information:
$ uname -a
Darwin jw-macbook-pro 14.4.0 Darwin Kernel Version 14.4.0: Tue May 5 14:17:52 PDT 2015; root:xnu-2782.30.4~3/RELEASE_X86_64 x86_64
$ sysctl -a | grep memsize
hw.memsize:<PHONE_NUMBER>4

$ vagrant --version
Vagrant 1.7.2
$ vboxwebsrv --version
Oracle VM VirtualBox web service Version 4.3.28
(C) 2007-2015 Oracle Corporation
All rights reserved.
4.3.28r100309

A little more than an hour and an error occurs:
$ deisctl start platform
● ▴ ■
■ ● ▴ Starting Deis...
▴ ■ ●

Storage subsystem...
deis-store-monitor.service: activating/start-pre
deis-store-monitor.service: active/running
deis-store-daemon.service: activating/start-pre
deis-store-daemon.service: active/running
deis-store-metadata.service: activating/start-pre
deis-store-metadata.service: active/running
<EMAIL_ADDRESS>activating/start-pre
<EMAIL_ADDRESS>activating/start-post
<EMAIL_ADDRESS>active/running
deis-store-volume.service: activating/start-pre
deis-store-volume.service: active/running
Logging subsystem...
deis-logger.service: activating/start-pre
deis-logger.service: active/running
deis-logspout.service: activating/start-pre
deis-logspout.service: active/running
Control plane...
deis-database.service: activating/start-pre
deis-controller.service: activating/start-pre
<EMAIL_ADDRESS>activating/start-pre
deis-controller.service: active/running
could not find unit: deis-database.service

On deis-01:
core@deis-01 ~ $ journalctl -u fleet|grep ERR
May 20 01:51:16 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:51:18 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: 101: Compare failed ([17159 != 17167]) [17210]
May 20 01:53:52 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:54:11 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:54:11 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:54:11 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:54:11 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:54:14 deis-01 fleetd[1047]: ERROR server.go:185: Server monitor triggered: Monitor timed out before successful heartbeat
May 20 01:54:14 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: 100: Key not found (/_coreos.com/fleet/lease/engine-leader) [18813]
May 20 01:54:35 deis-01 fleetd[1047]: ERROR engine.go:180: Engine leadership acquisition failed: timeout reached
May 20 01:54:43 deis-01 fleetd[1047]: ERROR engine.go:180: Engine leadership acquisition failed: timeout reached
May 20 01:54:43 deis-01 fleetd[1047]: ERROR engine.go:180: Engine leadership acquisition failed: timeout reached
May 20 01:54:44 deis-01 fleetd[1047]: ERROR engine.go:180: Engine leadership acquisition failed: timeout reached
May 20 01:54:53 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:54:55 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: 101: Compare failed ([18964 != 18968]) [18986]
May 20 01:58:55 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:58:55 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:58:55 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:58:55 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:58:55 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:58:57 deis-01 fleetd[1047]: ERROR engine.go:218: Engine leadership lost, renewal failed: 101: Compare failed ([21219 != 21379]) [21382]

And on deis-02 as well as deis-03:
core@deis-02 ~ $ journalctl -u fleet|grep ERR
May 20 01:54:14 deis-02 fleetd[1039]: ERROR server.go:185: Server monitor triggered: Monitor timed out before successful heartbeat
May 20 01:54:14 deis-02 fleetd[1039]: ERROR event.go:107: etcd watcher {Watch /_coreos.com/fleet/job} returned error: cancelled
May 20 01:54:14 deis-02 fleetd[1039]: ERROR event.go:107: etcd watcher {Watch /_coreos.com/fleet/job} returned error: cancelled
May 20 01:54:19 deis-02 fleetd[1039]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:54:24 deis-02 fleetd[1039]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:54:29 deis-02 fleetd[1039]: ERROR engine.go:218: Engine leadership lost, renewal failed: timeout reached
May 20 01:54:32 deis-02 fleetd[1039]: ERROR engine.go:218: Engine leadership lost, renewal failed: 101: Compare failed ([18817 != 18820]) [18856]
May 20 01:54:38 deis-02 fleetd[1039]: ERROR engine.go:180: Engine leadership acquisition failed: timeout reached
May 20 01:54:39 deis-02 fleetd[1039]: ERROR engine.go:180: Engine leadership acquisition failed: timeout reached
May 20 01:54:42 deis-02 fleetd[1039]: ERROR engine.go:180: Engine leadership acquisition failed: timeout reached
May 20 01:54:43 deis-02 fleetd[1039]: ERROR server.go:185: Server monitor triggered: Monitor timed out before successful heartbeat
May 20 01:54:43 deis-02 fleetd[1039]: ERROR event.go:107: etcd watcher {Watch /_coreos.com/fleet/job} returned error: cancelled
May 20 01:54:43 deis-02 fleetd[1039]: ERROR event.go:107: etcd watcher {Watch /_coreos.com/fleet/job} returned error: cancelled

@josephwinston What does fleetctl list-machines show on your hosts?  These errors indicate that fleet is having trouble communicating with etcd. I'd try to pin down if the issue lies with etcd or fleet.

somewhat related: https://github.com/coreos/fleet/issues/808

This sounds similar to the vagrant problems @iancoffey was describing.

ping @josephwinston, any news on this?

I'm going to close this issue as it hasn't seen any activity in a month. Please re-open it if this problem persists with Deis v1.7.3 or later.

I'm having this today on 1.9.1, discussing right now in irc with chaos, pasted below
9:17 AM <bffff_> morgun. I'm starting a new 1.9.1 cluster and it's stuck in a loop `deis-store-monitor.service: activating/start-pre` `deis-store-monitor.service: activating/auto-restart`. Any ideas how to fix?  I'd make an issue but thought I'd start here first
9:18 AM ⇐ gvilarino quit<EMAIL_ADDRESS>Quit: Leaving.
9:19 AM <chaos> bffff_, have looked into loogs?
9:19 AM <chaos> logs*
9:19 AM <bffff_> this is I ran  `deis install platform` and now `deis start platform`.
Aug 28 14:25:05 deis-v1.9.1-1 systemd[1]: deis-controller.service: Unit entered failed state
.
Aug 28 14:25:05 deis-v1.9.1-1 systemd[1]: deis-controller.service: Failed with result 'exit
-code'.


FIX: Inline notice - Allow spread operator on Props

Allow passing attribute from application level.

Hey @praveengh1 ! Thanks for the PR, looks good, except for a couple of places where I've suggested to use a code a bit differently...


How to add transit layer to map using react-google-maps ?

Please refer to Getting Help section in the README (or #469).


Recipes

Would be awesome if we could get some recipes for some different deploy jobs.
Today I self host on linux but I want to move it to azure but can't get som pretty basic things working. Example:

Use iojs
Do some preprocessing with gulp
Deploy the app

Note that Azure Web Apps includes Node, but not iojs at this point. It still might be possible to make it work by bringing your own, but I have not tried it.
To run arbitrary logic during deployment, please look at custom deployment scripts.

Thanks for the link, I'll try to tinker some more with it.
This repo https://github.com/felixrieseberg/iojs-azure shows how to use iojs on azure but it feels a bit hacky.
Not sure if this is on your table, but why isn't there a solution like on Heroku where you can just use something like this?
"engines": {
    "iojs": "2.x.x"
}

We just haven't seen many people as for iojs at this point, but it's certainly something we can look at if there is demand.

Okey, where is the correct place to ask for it?

The feedback site would be the best place, so that others can vote on it.
I'm curious: did you previously use Node, and switched to iojs? What were the primary factors for switching?

Thanks for the link.
I use node/iojs for development but lately switched to iojs to be able to use more es6 features.


RDK-44850: Wpeframework-HdmiCecSink Changes

Reason for change: HDMI-CEC key repeat for press and hold
Test Procedure: None
Risks: None

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.30 out of 31 committers have signed the CLA.:white_check_mark: klu339:white_check_mark: apatel859:white_check_mark: anand-ky:white_check_mark: kprasad96:white_check_mark: RDKDoc:white_check_mark: melhar098:white_check_mark: ksanth850:white_check_mark: karuna2git:white_check_mark: DineshkumarJP:white_check_mark: DamianoBaroneSky:white_check_mark: vdinak240:white_check_mark: dhivyapriyaMurugesan:white_check_mark: VenkateshUmmadiSetty:white_check_mark: ArikrishnanG:white_check_mark: ArchaChandran:white_check_mark: Rahamath17:white_check_mark: sborushevsky:white_check_mark: cmurug728:white_check_mark: tabbas651:white_check_mark: binuinbaraj:white_check_mark: rwarier:white_check_mark: arunl2910:white_check_mark: emutavchi:white_check_mark: modeveci:white_check_mark: PaviP98:white_check_mark: poojah58:white_check_mark: asurdej-comcast:white_check_mark: cmuhammedrafi:white_check_mark: Neethu379:white_check_mark: joseinweb:x: vinupalackalYou have signed the CLA already but the status is still pending? Let us recheck it.


KAFKA-13770: Restore compatibility with KafkaBasedLog using older Kafka brokers

The retryEndOffsets(…) method in TopicAdmin recently added (KAFKA-12879, #11797) to allow the KafkaBasedLog.start() method to retry any failures reading the last offsets for a topic. However, this introduce a regression when talking to older brokers (0.10.x or earlier).
The KafkaBasedLog already had logic that expected an UnsupportedVersionException thrown by the admin client when a Kafka API is not available on an older broker, but the new retry logic in TopicAdmin did not account for this and wrapped the exception, thereby breaking the KafkaBasedLog logic and preventing startup.
The fix is to propagate this UnsupportedVersionException from the TopicAdmin.retryEndOffsets(…) method. Added a new unit test that first replicated the problem before the fix, and verified the fix corrects the problem.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

No Connect-related failures in the builds, and a system test run of the Connect tests passed.


Cannot log into Nylas Mail - endless Password Management Error

Are there any related issues?

...
What operating system are you using?
...Kubuntu 16.04 / KDEneon
What version of Nylas Mail are you using?
...2.0.10
--
Bug?
Do you have any third-party plugins installed? If so, which ones?
...Can't start mail program
Is the issue related to a specific email provider (Gmail, Exchange, etc.)?
...Can't start mail program
Is the issue reproducible with a particular attachment, message, signature, etc?

...First error is:
Password Management Error
We couldn't store your password securely! For more information, visit https://support.nylas.com/hc/en-us/articles/223790028
Article at above link suggests installing libgnome-keyring-dev. The package already installed.
Second error:
Your NylasID is invalid. Please log out then log back in.
Actions like sending and receiving mail require this token. Please log back into your Nylas ID to restore it—your email accounts will not be removed in this process.
Closing second error re-opens first error again, then Nylas Mail restarts and same error loop begins again.
Log files have very odd permissions set. Last log (as far as I can tell, given the log file structure) contained only
{"host":"office","timestamp":"2017-04-14T19:31:06.359Z","payload":["ActionBridge: work Action Bridge Broadcasting: db-store-trigger"]}
{"host":"office","timestamp":"2017-04-14T19:32:06.790Z","payload":["ActionBridge: work Action Bridge Broadcasting: db-store-trigger"]}
Launching nylas-mail from terminal resulted in attached output:
bash_dump.txt
--
Feature Request?
Does this feature exist in another mail client or tool you use?
...

I have exactly the same issue! Using Arch Linux, Gnome-keyring-daemon initialized in .xinitrc, and bspwm.

Same issue here. Running Arch Linux with i3wm and gnome-keyring-daemon running.

So I got past the password prompt by adding the following changes to my system. Just make sure to back these files up first. Messing up these files can lock you out of your system.
I added this to the end of the /etc/pam.d/passwd
password	optional	pam_gnome_keyring.so
Then adding this the end of /etc/pam.d/login
password	required	pam_unix.so sha512 shadow nullok
password	optional	pam_gnome_keyring.so

Then I added this line to the end of my ~/.xinitrc
eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh)
export SSH_AUTH_SOCK

Rebooted and Nylas loads without the error

@jaredcrean 's edits in /etc/pam.d/* solved my keyring loop

sudo apt install gnome-keyring

Did not solve for me

This is broken for me as well, and the /etc/pam.d/* did not fix. I'm using Debian 9.

@etano seemingly so, I believe it works after starting a polkit daemon? In my case I have /usr/lib/xfce-polkit/xfce-polkit & and eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh) export SSH_AUTH_SOCK in my xinitrc

@ibrokemypie ultimately what fixed it for me was installing seahorse and creating a default


Add StainedClay

For some reason StainedClay was entirely missing, so here it is.

Good job, thanks.


Allow theme to configure page numbering to start on the cover page

It's currently possible to configure logical, integer page numbering (1, 2, 3, ...) to begin on the title page, toc page, body, or body offset. For screen-based PDFs that include a title page, it should be possible to configure the page numbering to start on the cover page. This allows the page number labeling to match the physical page numbering presented by certain PDF readers, which some users prefer.
Add support for the "cover" value to the page-numbering-start-at key in the theme.

cc: @divideconcept

The only slightly weird thing about this change is that it inadvertently inverts recto/verso for articles. That's because recto/verso is based on the virtual page number by default. But this can be flipped back by setting pdf-folio-placement=virtual-inverted (or physical-inverted since virtual and physical are interchangeable in this mode). So configure accordingly.


Unable to connect to AWS via SSO - AWSSDK.SSOOIDC could not be found or loaded

Describe the bug
I recently updated AWS Toolkit for Visual Studio 2022 to version 1.32.0 and now when trying to login in through AWS Explorer an error is occurring.
To Reproduce

Launch Visual Studio 2022.
Go to AWS Explorer.
Click on a profile that is configured to use SSO credentials.
Click 'Retry' below the "AWS login needed" prompt.
Wait.
See error

Expected behavior
A prompt to login using AWS SSO should appear and redirect the user to the AWS SSO login page.
Screenshots
Retry login:

Error message:

Computer (please complete the following information):

Windows Version: Window 11 Pro, 22000.739
Visual Studio Version: 17.2.5
AWS Toolkit for Visual Studio Version: <IP_ADDRESS>

Same issue here

I got the same error.  Is there anyway to downgrade the extension to a previous version like 1.29?  I could only find 1.27 for VS2019 in this repo but I can't find the previous version for VS2022.
Thanks!

https://marketplace.visualstudio.com/_apis/public/gallery/publishers/AmazonWebServices/vsextensions/AWSToolkitforVisualStudio2022/<IP_ADDRESS>/vspackage

Thanks @butekx, that worked!

So is this a bug in the latest toolkit on VS 2022?

Thank you for bringing this issue to our attention.  I was able to reproduce the issue and we are investigating further.

I am experiencing this exact same behavior in VS 2019 with the latest version of AWS Toolkit.

We have a fix for this issue. If you would like to try out an advance build containing the fix, please download and install one of these Toolkits, and let us know if you are able to connect in the Toolkit using SSO based credentials.

AWS Toolkit for Visual Studio 2019

Sha384 Hash: BA44A75906E6A71B076FE61BB8B3A1AF1245D1AF05B269DE8DDE83057F7F81C4B45FF8A7256B1FAB11ECBAC8FC10A469

AWS Toolkit for Visual Studio 2022

Sha384 Hash: 0222F7878653270DD12E005D4B09DE68736E0B14F36AE7BF06387749AA839F1A964AA7118A08679B834E21592AE5E58A

Version <IP_ADDRESS> of the Toolkit is now available. SSO based credentials are working in this version of the Toolkit.

I figured out my problem.  When I set up the AWS profile, I had typed in "JSON" as the output, changed it to lower case and that fixed it.  Upper case works everywhere else, like VS Code and the AWS CLI.


Error creating: admission webhook "mutate.openfeature.dev" denied the request: ServiceAccount "default" not found

On k8s v1.22.9, deploying open feature operator following the starting guide (using the following commands) are failing.
kubectl apply -f https://github.com/open-feature/open-feature-operator/releases/download/v0.2.34/release.yaml

kubectl apply -n workload -f - <<EOF
apiVersion: core.openfeature.dev/v1alpha2
kind: FeatureFlagConfiguration
metadata:
  name: sample-flags
spec:
  featureFlagSpec:
    flags:
      foo:
        state: "ENABLED"
        variants:
          "bar": "BAR"
          "baz": "BAZ"
        defaultVariant: "bar"
        targeting: {}
EOF

kubectl apply -n workload -f - <<EOF
apiVersion: core.openfeature.dev/v1alpha3
kind: FlagSourceConfiguration
metadata:
  name: flag-source-configuration
spec:
  sources:
  - source: workload/sample-flags
    provider: kubernetes
  port: 8080
EOF

kubectl apply -n workload -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox-curl
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-busybox-curl-app
  template:
    metadata:
      labels:
        app: my-busybox-curl-app
      annotations:
        # here are the annotations for OpenFeature Operator
        openfeature.dev/enabled: "true"
        openfeature.dev/flagsourceconfiguration: "workload/flag-source-configuration"
    spec:
      containers:
        - name: busybox
          image: yauritux/busybox-curl:latest
          ports:
            - containerPort: 80
          args:
            - sleep
            - "30000"
EOF

kubectl describe replicaset busybox-curl-6bf67b44cd

Error creating: admission webhook "mutate.openfeature.dev" denied the request: ServiceAccount "default" not found

open-feature-operator-controller-manager-7bfb56fb6f-znhnh manager 2023-07-21T08:56:27Z	DEBUG	controller-runtime.webhook.webhooks	received request	{"webhook": "/mutate-v1-pod", "UID": "9f978d5f-e98a-45f4-b3d4-b119b2436c48", "kind": "/v1, Kind=Pod", "resource": {"group":"","version":"v1","resource":"pods"}}
open-feature-operator-controller-manager-7bfb56fb6f-znhnh manager 2023-07-21T08:56:27Z	DEBUG	mutating-pod-webhook	Fetching serviceAccount: /default
open-feature-operator-controller-manager-7bfb56fb6f-znhnh manager 2023-07-21T08:56:27Z	DEBUG	mutating-pod-webhook	ServiceAccount not found: /default
open-feature-operator-controller-manager-7bfb56fb6f-znhnh manager 2023-07-21T08:56:27Z	DEBUG	controller-runtime.webhook.webhooks	wrote response	{"webhook": "/mutate-v1-pod", "code": 403, "reason": "ServiceAccount \"default\" not found", "UID": "9f978d5f-e98a-45f4-b3d4-b119b2436c48", "allowed": false}

Following the issue what's the service account controller?

The service account controller should be part of the kube-controller-manager. you could also manually create the default service account by running kubectl create sa default but this should typically be done by the controller mentioned above.

@beeme1mr a default SA is already present in the operator and application namespace.
kubectl -nopen-feature-operator-system get sa
NAME                                       SECRETS   AGE
default                                    1         7h2m
open-feature-operator-controller-manager   1         7h2m
open-feature-operator-flagd-proxy          1         7h2m

Hey @L3o-pold can you check the workload namespace for the default SA?

Sure @beeme1mr
kubectl -nworkload get sa
NAME                       SECRETS   AGE
default                    1         394d

Is there any chance you could upgrade your Kubernetes cluster? Version 1.22.9 End of Life date was October 2022. I'm not sure if that would address this issue but the error you're experiencing is unexpected in a healthy cluster.
@thisthat @Kavindu-Dodan could you please take a look when you have a moment?

@beeme1mr unfortunately not yet but I can try with a more recent cluster to see if I can reproduce :)

Tried on a v1.24.6 cluster and it worked as expected

@L3o-pold I hope you are following the quick start guide.
My assumption is that you have issues updating cluster role bindings, which is needed for K8s sync option (allowing flagd sidecar to access custom resources we define through OFO)
Can you run following commands and see if you see the cluster role binding entry,
k describe ClusterRoleBinding open-feature-operator-flagd-kubernetes-sync
You should see following,
ServiceAccount  default  workload
If this is not there, it could be a cluster issue/permission issue.
You can get logs and see with  k  logs deployment/open-feature-operator-controller-manager -n open-feature-operator-system

@Kavindu-Dodan the cluster role binding entry is not present and I don't see useful information in the log
I0721 15:52:47.384330       1 request.go:690] Waited for 1.030908834s due to client-side throttling, not priority and fairness, request: GET:https://<IP_ADDRESS>:443/apis/acme.h2.infomaniak.com/v1alpha1?timeout=32s
2023-07-21T15:52:49Z	INFO	controller-runtime.metrics	Metrics server is starting to listen	{"addr": "<IP_ADDRESS>:8080"}
2023-07-21T15:52:49Z	INFO	controller-runtime.builder	skip registering a mutating webhook, object does not implement admission.Defaulter or WithDefaulter wasn't called	{"GVK": "core.openfeature.dev/v1alpha1, Kind=FeatureFlagConfiguration"}
2023-07-21T15:52:49Z	INFO	controller-runtime.builder	skip registering a validating webhook, object does not implement admission.Validator or WithValidator wasn't called	{"GVK": "core.openfeature.dev/v1alpha1, Kind=FeatureFlagConfiguration"}
2023-07-21T15:52:49Z	INFO	controller-runtime.webhook	Registering webhook	{"path": "/convert"}
2023-07-21T15:52:49Z	INFO	controller-runtime.builder	Conversion webhook enabled	{"GVK": "core.openfeature.dev/v1alpha1, Kind=FeatureFlagConfiguration"}
2023-07-21T15:52:49Z	INFO	controller-runtime.builder	skip registering a mutating webhook, object does not implement admission.Defaulter or WithDefaulter wasn't called	{"GVK": "core.openfeature.dev/v1alpha1, Kind=FlagSourceConfiguration"}
2023-07-21T15:52:49Z	INFO	controller-runtime.builder	skip registering a validating webhook, object does not implement admission.Validator or WithValidator wasn't called	{"GVK": "core.openfeature.dev/v1alpha1, Kind=FlagSourceConfiguration"}
2023-07-21T15:52:49Z	INFO	controller-runtime.builder	Conversion webhook enabled	{"GVK": "core.openfeature.dev/v1alpha1, Kind=FlagSourceConfiguration"}
2023-07-21T15:52:49Z	INFO	controller-runtime.webhook	Registering webhook	{"path": "/mutate-v1-pod"}
2023-07-21T15:52:49Z	INFO	controller-runtime.webhook	Registering webhook	{"path": "/validate-v1alpha1-featureflagconfiguration"}
2023-07-21T15:52:49Z	INFO	setup	starting manager
2023-07-21T15:52:49Z	INFO	setup	restoring flagd-kubernetes-sync cluster role binding subjects from current cluster state
2023-07-21T15:52:49Z	INFO	controller-runtime.webhook.webhooks	Starting webhook server
2023-07-21T15:52:49Z	INFO	Starting server	{"kind": "health probe", "addr": "[::]:8081"}
2023-07-21T15:52:49Z	INFO	Starting server	{"path": "/metrics", "kind": "metrics", "addr": "<IP_ADDRESS>:8080"}
2023-07-21T15:52:49Z	INFO	controller-runtime.certwatcher	Updated current TLS certificate
2023-07-21T15:52:49Z	INFO	controller-runtime.webhook	Serving webhook server	{"host": "", "port": 9443}
2023-07-21T15:52:49Z	INFO	controller-runtime.certwatcher	Starting certificate watcher
I0721 15:52:51.450587       1 leaderelection.go:248] attempting to acquire leader lease open-feature-operator-system/131bf64c.openfeature.dev...
I0721 15:52:51.474775       1 leaderelection.go:258] successfully acquired lease open-feature-operator-system/131bf64c.openfeature.dev
2023-07-21T15:52:51Z	DEBUG	events	open-feature-operator-controller-manager-7bfb56fb6f-kwcs4_431ce796-4658-4887-8d93-b12051a432b7 became leader	{"type": "Normal", "object": {"kind":"Lease","namespace":"open-feature-operator-system","name":"131bf64c.openfeature.dev","uid":"e3d84cc5-471c-4cb5-a6dd-9561fab81e95","apiVersion":"coordination.k8s.io/v1","resourceVersion":"1515324816"}, "reason": "LeaderElection"}
2023-07-21T15:52:51Z	INFO	Starting EventSource	{"controller": "featureflagconfiguration", "controllerGroup": "core.openfeature.dev", "controllerKind": "FeatureFlagConfiguration", "source": "kind source: *v1alpha1.FeatureFlagConfiguration"}
2023-07-21T15:52:51Z	INFO	Starting EventSource	{"controller": "featureflagconfiguration", "controllerGroup": "core.openfeature.dev", "controllerKind": "FeatureFlagConfiguration", "source": "kind source: *v1.ConfigMap"}
2023-07-21T15:52:51Z	INFO	Starting Controller	{"controller": "featureflagconfiguration", "controllerGroup": "core.openfeature.dev", "controllerKind": "FeatureFlagConfiguration"}
2023-07-21T15:52:51Z	INFO	Starting EventSource	{"controller": "flagsourceconfiguration", "controllerGroup": "core.openfeature.dev", "controllerKind": "FlagSourceConfiguration", "source": "kind source: *v1alpha1.FlagSourceConfiguration"}
2023-07-21T15:52:51Z	INFO	Starting Controller	{"controller": "flagsourceconfiguration", "controllerGroup": "core.openfeature.dev", "controllerKind": "FlagSourceConfiguration"}
2023-07-21T15:52:52Z	INFO	Starting workers	{"controller": "featureflagconfiguration", "controllerGroup": "core.openfeature.dev", "controllerKind": "FeatureFlagConfiguration", "worker count": 1}
2023-07-21T15:52:52Z	INFO	Starting workers	{"controller": "flagsourceconfiguration", "controllerGroup": "core.openfeature.dev", "controllerKind": "FlagSourceConfiguration", "worker count": 1}
2023-07-21T15:52:54Z	DEBUG	controller-runtime.webhook.webhooks	received request	{"webhook": "/validate-v1alpha1-featureflagconfiguration", "UID": "e7da5bdd-e0e4-46db-a740-48a9422c9ac4", "kind": "core.openfeature.dev/v1alpha1, Kind=FeatureFlagConfiguration", "resource": {"group":"core.openfeature.dev","version":"v1alpha1","resource":"featureflagconfigurations"}}
2023-07-21T15:52:54Z	DEBUG	controller-runtime.webhook.webhooks	wrote response	{"webhook": "/validate-v1alpha1-featureflagconfiguration", "code": 200, "reason": "", "UID": "e7da5bdd-e0e4-46db-a740-48a9422c9ac4", "allowed": true}
2023-07-21T15:52:54Z	INFO	FeatureFlagConfiguration Controller	ReconcilingFeatureFlagConfiguration
2023-07-21T15:52:54Z	DEBUG	controller-runtime.webhook.webhooks	received request	{"webhook": "/validate-v1alpha1-featureflagconfiguration", "UID": "ab3fe737-a4c0-4b27-85aa-b2f2cd309e43", "kind": "core.openfeature.dev/v1alpha1, Kind=FeatureFlagConfiguration", "resource": {"group":"core.openfeature.dev","version":"v1alpha1","resource":"featureflagconfigurations"}}
2023-07-21T15:52:54Z	DEBUG	controller-runtime.webhook.webhooks	wrote response	{"webhook": "/validate-v1alpha1-featureflagconfiguration", "code": 200, "reason": "", "UID": "ab3fe737-a4c0-4b27-85aa-b2f2cd309e43", "allowed": true}
2023-07-21T15:52:54Z	INFO	FeatureFlagConfiguration Controller	No service provider specified for FeatureFlagConfiguration, using FlagD
2023-07-21T15:52:54Z	DEBUG	controller-runtime.webhook.webhooks	received request	{"webhook": "/validate-v1alpha1-featureflagconfiguration", "UID": "def64d41-01bf-4346-b1bc-dfaadba89fd7", "kind": "core.openfeature.dev/v1alpha1, Kind=FeatureFlagConfiguration", "resource": {"group":"core.openfeature.dev","version":"v1alpha1","resource":"featureflagconfigurations"}}
2023-07-21T15:52:54Z	DEBUG	controller-runtime.webhook.webhooks	wrote response	{"webhook": "/validate-v1alpha1-featureflagconfiguration", "code": 200, "reason": "", "UID": "def64d41-01bf-4346-b1bc-dfaadba89fd7", "allowed": true}
2023-07-21T15:52:54Z	INFO	FeatureFlagConfiguration Controller	Finished Reconciling FeatureFlagConfiguration
2023-07-21T15:52:54Z	INFO	FeatureFlagConfiguration Controller	ReconcilingFeatureFlagConfiguration
2023-07-21T15:52:54Z	INFO	FeatureFlagConfiguration Controller	Finished Reconciling FeatureFlagConfiguration
2023-07-21T15:52:54Z	INFO	FlagSourceConfiguration Controller	Searching for FlagSourceConfiguration
2023-07-21T15:52:54Z	INFO	FlagSourceConfiguration Controller	Finished Reconciling FlagSourceConfiguration
2023-07-21T15:53:00Z	DEBUG	controller-runtime.webhook.webhooks	received request	{"webhook": "/mutate-v1-pod", "UID": "0d0e4fa8-8b1f-4f90-a2a7-a0525ae0d635", "kind": "/v1, Kind=Pod", "resource": {"group":"","version":"v1","resource":"pods"}}
2023-07-21T15:53:00Z	DEBUG	controller-runtime.webhook.webhooks	received request	{"webhook": "/mutate-v1-pod", "UID": "6780b05e-72d5-49a5-8960-48db56ed05ee", "kind": "/v1, Kind=Pod", "resource": {"group":"","version":"v1","resource":"pods"}}
2023-07-21T15:53:00Z	DEBUG	controller-runtime.webhook.webhooks	wrote response	{"webhook": "/mutate-v1-pod", "code": 200, "reason": "OpenFeature is disabled", "UID": "6780b05e-72d5-49a5-8960-48db56ed05ee", "allowed": true}
2023-07-21T15:53:00Z	DEBUG	controller-runtime.webhook.webhooks	wrote response	{"webhook": "/mutate-v1-pod", "code": 200, "reason": "OpenFeature is disabled", "UID": "0d0e4fa8-8b1f-4f90-a2a7-a0525ae0d635", "allowed": true}
2023-07-21T15:53:00Z	DEBUG	controller-runtime.webhook.webhooks	received request	{"webhook": "/mutate-v1-pod", "UID": "c83f2146-4f4b-42a4-a0d0-0e530e9c7f6a", "kind": "/v1, Kind=Pod", "resource": {"group":"","version":"v1","resource":"pods"}}
2023-07-21T15:53:00Z	DEBUG	controller-runtime.webhook.webhooks	received request	{"webhook": "/mutate-v1-pod", "UID": "e3e22004-a814-41c7-bab2-4468bf17c324", "kind": "/v1, Kind=Pod", "resource": {"group":"","version":"v1","resource":"pods"}}
2023-07-21T15:53:00Z	DEBUG	controller-runtime.webhook.webhooks	wrote response	{"webhook": "/mutate-v1-pod", "code": 200, "reason": "OpenFeature is disabled", "UID": "c83f2146-4f4b-42a4-a0d0-0e530e9c7f6a", "allowed": true}
2023-07-21T15:53:00Z	DEBUG	controller-runtime.webhook.webhooks	wrote response	{"webhook": "/mutate-v1-pod", "code": 200, "reason": "OpenFeature is disabled", "UID": "e3e22004-a814-41c7-bab2-4468bf17c324", "allowed": true}
2023-07-21T15:54:00Z	DEBUG	controller-runtime.webhook.webhooks	received request	{"webhook": "/mutate-v1-pod", "UID": "5df4db55-d5ea-42ef-8607-d2af7dcbfe26", "kind": "/v1, Kind=Pod", "resource": {"group":"","version":"v1","resource":"pods"}}
2023-07-21T15:54:00Z	DEBUG	controller-runtime.webhook.webhooks	received request	{"webhook": "/mutate-v1-pod", "UID": "96924f34-373b-4529-8576-32dd3167dbe3", "kind": "/v1, Kind=Pod", "resource": {"group":"","version":"v1","resource":"pods"}}
2023-07-21T15:54:00Z	DEBUG	controller-runtime.webhook.webhooks	wrote response	{"webhook": "/mutate-v1-pod", "code": 200, "reason": "OpenFeature is disabled", "UID": "5df4db55-d5ea-42ef-8607-d2af7dcbfe26", "allowed": true}
2023-07-21T15:54:00Z	DEBUG	controller-runtime.webhook.webhooks	wrote response	{"webhook": "/mutate-v1-pod", "code": 200, "reason": "OpenFeature is disabled", "UID": "96924f34-373b-4529-8576-32dd3167dbe3", "allowed": true}
2023-07-21T15:54:00Z	DEBUG	controller-runtime.webhook.webhooks	received request	{"webhook": "/mutate-v1-pod", "UID": "ba94689b-22f8-4810-ab67-817d4d8a7a45", "kind": "/v1, Kind=Pod", "resource": {"group":"","version":"v1","resource":"pods"}}
2023-07-21T15:54:00Z	DEBUG	controller-runtime.webhook.webhooks	received request	{"webhook": "/mutate-v1-pod", "UID": "1b972e01-fac4-48e5-b1e7-0222569006f7", "kind": "/v1, Kind=Pod", "resource": {"group":"","version":"v1","resource":"pods"}}
2023-07-21T15:54:00Z	DEBUG	controller-runtime.webhook.webhooks	wrote response	{"webhook": "/mutate-v1-pod", "code": 200, "reason": "OpenFeature is disabled", "UID": "ba94689b-22f8-4810-ab67-817d4d8a7a45", "allowed": true}
2023-07-21T15:54:00Z	DEBUG	controller-runtime.webhook.webhooks	wrote response	{"webhook": "/mutate-v1-pod", "code": 200, "reason": "OpenFeature is disabled", "UID": "1b972e01-fac4-48e5-b1e7-0222569006f7", "allowed": true}

the cluster role binding entry is not present and I don't see useful information in the log

strange, if end to end workflow works (flag evaluation happens as with a simple curl), then everything is workign fine. But I am not sure why you still don't have the CRB entry and the log line  mutating-pod-webhook	ServiceAccount not found: /default is also strange
Were you able to see falg evaluation as described at our validation step - https://github.com/open-feature/open-feature-operator/blob/main/docs/quick_start.md#7-validate-deployment--flag-evaluation

No, provided sample are from the v1.22.9 cluster witch fails to run the busybox-curl with the error provided in the original post.
Running the same example on a 1.24 cluster works without issue.

@Kavindu-Dodan yes the entry is there. Maybe we need to add the minimum Kubernetes version required.

@L3o-pold  that's a really good point. Will follow up and see how we can do this.

@Kavindu-Dodan would be really nice to also use a matrix of k8s version for end to end test (with kind). Maybe we'll see that test are falling on some Kubernetes version and then fixing it with PRs.

Hey @L3o-pold, I'm looking into this right now. It wasn't our intention to revert this functionality.

@L3o-pold We have a fix here, and added some e2e tests for v1.22 onward to prevent similar regressions. If we break 1.22 support in the future, we'll know it.


Create Protein table so users can see list of protein features and coordinates

Rather than having multiple duplicate feature names, if multiple are named "Disordered" they will be relabeled as "Disordered_1", "Disordered_2", etc. This will make it easier for a user to pick a specific area when running the "compare_by_protein_feature" predicate.
I also added an assertion to verify that they are counted properly.
This will close #176
EDIT: Updated to reflect updates in #176
This PR creates a class called ProteinViewable that prints a table that shows the protein features and coordinates.

Example!


Makefile has MUNGERS and mungegithub/submit-queue/deployment.yaml duplicates the list

In mungegithub/Makefile there is a list of all mungers in MUNGERS.
The same list is duplicated in mungegithub/submique-queue/deployment.yaml making things kind of confusing.
We should probably find a way to DRY.

We should just remove the one in the makefile, since we never use the value except in local_dryrun, and I don't think we even need that target anymore.

This issue was moved to kubernetes/test-infra#1634


Fixed issues with url.py

Fixed issues with url.py and removed versions from requirements.txt except for django == 3.0
This now works when used with python 3.9 any higher and it breaks

I should mention, this works with Python 3.9 it does not work with Python 3.10


HardwareSerial support

Did you ever add hardware support to this library?
Thanks for a great library! :+1:

No, I did not. I very much appreciate your thank you!


Add plan expiry date to company snapshot

Use CompanySubscriptions.planCurrentPeriodEndDate
null if plan is Cancelled
Name the field subscriptionRenewalDate as per taxonomy

Field needs to be added to Hubspot for the customer.
@alexey-rise @ezequielc please review. Thanks!


[Trailblazer Clues] Hard Step is classified as Asgarnia instead of Misthalin in error

This issue is for the external plugin: {Trailblazer Clues}
The hard step "Talk to Sir Prysin in Varrock Palace" is mistakenly classified as an Asgarnia clue. While most of the White Knights are in fact in Falador, Sir Prysin is in Varrock and so this should be classified as a Misthalin clue.

Good shout, not sure what happened here. Will be in v1.4.1