text:
Reintroduce mapped dirs back

b/c we can't do readwritemany volumes in our openshift instance
TODO

[x] docs
[x] create a new project for the pod (or run them in a pre-set-up project; might need to set up a SA for this)
[x] be awesome

Laptop CI status: passed
$ pytest-3 -vv
========= test session starts =========
platform linux -- Python 3.7.3, pytest-3.9.3, py-1.7.0, pluggy-0.8.1 -- /usr/bin/python3
cachedir: .pytest_cache
rootdir: /home/tt/g/packit-service/sandcastle, inifile:
plugins: cov-2.6.0
collected 28 items

tests/e2e/test_ironman.py::test_basic_e2e_inside PASSED                               [  3%]
tests/e2e/test_ironman.py::test_run_failure PASSED                                    [  7%]
tests/e2e/test_ironman.py::test_exec_failure PASSED                                   [ 10%]
tests/e2e/test_ironman.py::test_dir_sync SKIPPED                                      [ 14%]
tests/e2e/test_ironman.py::test_pod_sa_not_in_sandbox SKIPPED                         [ 17%]
tests/e2e/test_ironman.py::test_exec_succ_pod PASSED                                  [ 21%]
tests/e2e/test_ironman.py::test_local_path_e2e_inside_w_exec PASSED                   [ 25%]
tests/e2e/test_ironman.py::test_file_got_changed PASSED                               [ 28%]
tests/e2e/test_ironman.py::test_md_e2e PASSED                                         [ 32%]
tests/e2e/test_ironman.py::test_md_new_namespace PASSED                               [ 35%]
tests/e2e/test_ironman.py::test_from_pod[test_basic_e2e_inside-None] P                [ 39%]
tests/e2e/test_ironman.py::test_from_pod[test_exec_failure-None] PASSE                [ 42%]
tests/e2e/test_ironman.py::test_from_pod[test_run_failure-None] PASSED                [ 46%]
tests/e2e/test_ironman.py::test_from_pod[test_dir_sync-kwargs3] PASSED                [ 50%]
tests/e2e/test_ironman.py::test_from_pod[test_pod_sa_not_in_sandbox-No                [ 53%]
tests/e2e/test_ironman.py::test_from_pod[test_exec_succ_pod-None] PASS                [ 57%]
tests/e2e/test_ironman.py::test_from_pod[test_local_path_e2e_inside_w_                [ 60%]
tests/e2e/test_ironman.py::test_from_pod[test_file_got_changed-None] P                [ 64%]
tests/e2e/test_ironman.py::test_from_pod[test_md_e2e-None] PASSED                     [ 67%]
tests/e2e/test_ironman.py::test_from_pod[test_md_new_namespace-kwargs9                [ 71%]
tests/unit/test_pod_and_env.py::test_is_pod_already_deployed PASSED                   [ 75%]
tests/unit/test_pod_and_env.py::test_pod_not_deployed PASSED                          [ 78%]
tests/unit/test_pod_and_env.py::test_env_image_vars[env_dict0-env_imag                [ 82%]
tests/unit/test_pod_and_env.py::test_env_image_vars[env_dict1-env_imag                [ 85%]
tests/unit/test_pod_and_env.py::test_env_image_vars[env_dict2-env_imag                [ 89%]
tests/unit/test_pod_and_env.py::test_env_image_vars[env_dict3-env_imag                [ 92%]
tests/unit/test_pod_and_env.py::test_env_image_vars[env_dict4-env_imag                [ 96%]
tests/unit/test_pod_and_env.py::test_manifest PASSED                                  [100%]

========== 26 passed, 2 skipped in 193.57 seconds ============

Tests are passing except two:
make check
pytest -vv ./tests
=========================================================================== test session starts ============================================================================
platform darwin -- Python 3.7.2, pytest-4.6.3, py-1.8.0, pluggy-0.12.0 -- /Users/phracek/.pyenv/versions/3.7.2/bin/python3.7
cachedir: .pytest_cache
rootdir: /Users/phracek/work/programming/sandcastle
plugins: celery-4.3.0
collected 28 items

tests/e2e/test_ironman.py::test_basic_e2e_inside PASSED                                                                                [  3%]
tests/e2e/test_ironman.py::test_run_failure PASSED                                                                                [  7%]
tests/e2e/test_ironman.py::test_exec_failure PASSED                                                                                [ 10%]
tests/e2e/test_ironman.py::test_dir_sync SKIPPED                                                                                [ 14%]
tests/e2e/test_ironman.py::test_pod_sa_not_in_sandbox SKIPPED                                                                                [ 17%]
tests/e2e/test_ironman.py::test_exec_succ_pod PASSED                                                                                [ 21%]
tests/e2e/test_ironman.py::test_local_path_e2e_inside_w_exec PASSED                                                                                [ 25%]
tests/e2e/test_ironman.py::test_file_got_changed PASSED                                                                                [ 28%]
tests/e2e/test_ironman.py::test_md_e2e PASSED                                                                                [ 32%]
tests/e2e/test_ironman.py::test_md_new_namespace FAILED                                                                                [ 35%]
tests/e2e/test_ironman.py::test_from_pod[test_basic_e2e_inside-None] PASSED                                                                                [ 39%]
tests/e2e/test_ironman.py::test_from_pod[test_exec_failure-None] PASSED                                                                                [ 42%]
tests/e2e/test_ironman.py::test_from_pod[test_run_failure-None] PASSED                                                                                [ 46%]
tests/e2e/test_ironman.py::test_from_pod[test_dir_sync-kwargs3] PASSED                                                                                [ 50%]
tests/e2e/test_ironman.py::test_from_pod[test_pod_sa_not_in_sandbox-None] PASSED                                                                                [ 53%]
tests/e2e/test_ironman.py::test_from_pod[test_exec_succ_pod-None] PASSED                                                                                [ 57%]
tests/e2e/test_ironman.py::test_from_pod[test_local_path_e2e_inside_w_exec-None] PASSED                                                                              [ 60%]
tests/e2e/test_ironman.py::test_from_pod[test_file_got_changed-None] PASSED                                                                                [ 64%]
tests/e2e/test_ironman.py::test_from_pod[test_md_e2e-None] PASSED                                                                                [ 67%]
tests/e2e/test_ironman.py::test_from_pod[test_md_new_namespace-kwargs9] FAILED                                                                                [ 71%]
tests/unit/test_pod_and_env.py::test_is_pod_already_deployed PASSED                                                                                [ 75%]
tests/unit/test_pod_and_env.py::test_pod_not_deployed PASSED                                                                                [ 78%]
tests/unit/test_pod_and_env.py::test_env_image_vars[env_dict0-env_image_vars0] PASSED                                                                                [ 82%]
tests/unit/test_pod_and_env.py::test_env_image_vars[env_dict1-env_image_vars1] PASSED                                                                                [ 85%]
tests/unit/test_pod_and_env.py::test_env_image_vars[env_dict2-env_image_vars2] PASSED                                                                                [ 89%]
tests/unit/test_pod_and_env.py::test_env_image_vars[env_dict3-env_image_vars3] PASSED                                                                                [ 92%]
tests/unit/test_pod_and_env.py::test_env_image_vars[env_dict4-env_image_vars4] PASSED                                                                                [ 96%]
tests/unit/test_pod_and_env.py::test_manifest PASSED

which are caused by missing OpenShift policies.
E               assert 'no RBAC policy matched' in '*   Trying 172.30.0.1...\n* TCP_NODELAY set\n* Connected to 172.30.0.1 (172.30.0.1) port 443 (#0)\n* ALPN, offering h...system:anonymous\\" cannot \\"get\\" on \\"/metrics\\"",\n  "reason": "Forbidden",\n  "details": {},\n  "code": 403\n}'

Of course, I have run only oc adm policy add-role-to-user edit system:serviceaccount:myproject:default

It's the other way around actually: the test verifies that the pod can't access the /metrics endpoint in the apiserver. The thing is that your apiserver responds with different error message than mine.

I am using OpenShift 3.10.
oc version
oc v3.10.0+dd10d17
kubernetes v1.10.0+b81c8f8
features: Basic-Auth

Server https://127.0.0.1:8443
openshift v3.10.0+7d0b7ea-117
kubernetes v1.10.0+b81c8f8

I have 3.11 and just pushed a commit which should check things less strictly.

All tests are now passing.
========== 26 passed, 2 skipped, 1 warnings in 191.66 seconds ===========

authors: TomasTomecek phracek

repo: packit-service/sandcastle


text:
git: Disable detecting renames

Updating repositories with a large number of files might fail when file
renames are detected by Git. This happens when merge is involved in some
way, for example during cherry-picks.
Tried increasing merge.renameLimit to 999999, but this did not
reliably fix the issues. Disabling rename detection did.
If my understanding is correct this will cause renames to show up as
separate rm and add operations in the Git history. This should be
fine as the usefulness of the source-git history is already limited.
Fixes #157.
Signed-off-by: Hunor Csomortáni csomh@redhat.com

@TomasTomecek ptal and let me know if you think this change is okay or not. History will be changed somewhat (no renames), but I think that's fine as it's already pretty noisy.

@TomasTomecek ptal and let me know if you think this change is okay or not. History will be changed somewhat (no renames), but I think that's fine as it's already pretty noisy.

should we just skip kernel tests in CI?

This is what I did for the last couple of PRs :confused:  I think the kernel test takes up too much storage. Discussing and fixing this could be done outside of this PR. WDYT?

should we just skip kernel tests in CI?

This is what I did for the last couple of PRs :confused:  I think the kernel test takes up too much storage. Discussing and fixing this could be done outside of this PR. WDYT?

should we just skip kernel tests in CI?

This is what I did for the last couple of PRs confused I think the kernel test takes up too much storage. Discussing and fixing this could be done outside of this PR. WDYT?

agreed
:rocket:

should we just skip kernel tests in CI?

This is what I did for the last couple of PRs confused I think the kernel test takes up too much storage. Discussing and fixing this could be done outside of this PR. WDYT?

agreed
:rocket:

source: gharchive/pull-request

authors: TomasTomecek csomh

repo: packit/dist-git-to-source-git

license: MIT

license_type: permissive

license_source: github-api


text:
fix(tests): account for enable_net=False default

TODO:

[x] Write new tests or update the old ones to cover new functionality.

Needs: https://github.com/packit/packit/pull/1825
Release notes present in the Packit PR.

and since the PR is not merged yet, the tests should fail.

o_O
tests/unit/test_copr_build.py::test_submit_copr_build[True-True-buildopts0] PASSED                                                                                [ 37%]
tests/unit/test_copr_build.py::test_submit_copr_build[False-True-buildopts1] PASSED                                                                                [ 37%]
tests/unit/test_copr_build.py::test_submit_copr_build[True-False-buildopts2] PASSED                                                                                [ 38%]
tests/unit/test_copr_build.py::test_submit_copr_build[False-False-buildopts3] PASSED                                                                                [ 38%]

locally

oh right, RPMs

recheck

no clue honestly: pre-commit passes for me locally & the PR is rebased

regate

repo: packit/packit-service


text:
fix(copr): do not overwrite chroots

Signed-off-by: Matej Focko mfocko@redhat.com
Fixes packit/packit-service#1425
RELEASE NOTES BEGIN
TODO
RELEASE NOTES END

recheck

Failing test should be fixed by packit/packit-service#1436

nice, such an easy fix
do we need a new test case to cover the change in the behaviour?

removed test case was checking overwriting, there's one where we build subset and other one for expanding, it was covered already

recheck

repo: packit/packit


text:
Added IncludeContextAttributes from Serilog Logger

Hello
The existing library is not supporting the context attributes as generated by the serilog logger.
Only the predefined tags and fields are generated in InfuxDB bucket.
I have extended the library, that now on demand , it will create the context attributes as tags in InfluxDB bucket.
Please review

Thanks for your PR, I will look on phone as in vacation. Will not merge before August

If someone is still interested in this, it should be implemented like in #16

authors: pada57 tom-englert tyagira


text:
Fixed PHPUnit deprecation warning

One test was not passing because of a deprecation warning on PHPUnit's old getMock() method.

Coverage remained the same at 76.273% when pulling cab7a9c796ba3fe2f6c38e63b035301eabbe55af on Bilge:deprecated-mock-syntax into 897c2e7807a49cec7da9395827df17168232cfe0 on padraic:master.

authors: Bilge coveralls

repo: padraic/mockery

license_source: bigquery


text:
Adding pry_byebug to default Gemfile

Since padrino/padrino-framework@2a2600a7f9f594aeb3ae8bec3da04ab80d64bbf0 Padrino uses Pry if available. Debugging is a common issue and I think that Pry paired with pry_byebug is the best solution. The only downside that I can see is that it would introduce an external dependency which might be not what we want.

Probably not gonna happen. Padrino tries to stay lean and as far as I understand the use of pry_byebug is pretty fringe and limited by MRI version. You can always add it to your Gemfile by hand.

source: gharchive/issue

authors: Quintasan ujifgc

repo: padrino/padrino-framework


text:
[Bug] 0.15.2  undefined method `update_attributes' for all models on edit/update submission on clean admin app and older apps

Do you want to request a feature or report a bug?
Bug!  🐛
(weird one and one of the very last things to fix before AArk app is fully upgraded. =] ).
What is the current behavior?
Whenever an edit action is performed and submitted, both in my upgraded app and in a fresh padrino app using the padrino-gen admin generator in 0.15.2  (so pure clean one), submission gives a:
undefined method update_attributes' ` error.
For AR/AS/AM 7.0.4 and postgres (also, in the  cleanly generated padrino app, with SQLIte).
To reproduce.
padrino-gen admin-test --orm active-record -e haml
cd admin-test
bundle install --binstubs
padrino-gen admin
rake db:migrate
rake db:seed

then log into application. Create a new account. Try to edit it. Submit will throw the error.
Backtrace:

NoMethodError at /admin/accounts/update/2
undefined method `update_attributes' for #<Account id: 2, name: "Some Dude", surname: "lastname", email: "yabba@dabbadoo.com", crypted_password: "$2a$12$fDGcoogxqHS3EEngUSJDDO6PEvGUcVnFI3dOBzE.tGT...", role: "admin", created_at: "2023-01-11 10:57:25.735345000 +0000", updated_at: "2023-01-11 10:57:25.735345000 +0000">

    file: attribute_methods.rb location: method_missing line: 458

 /Users/daryl/Code/dev/admin-test/admin/controllers/accounts.rb in block (2 levels) in <top (required)>

          if @account.update_attributes(params[:account])

/Users/daryl/Code/dev/admin-test/lib/connection_pool_management_middleware.rb in block in call

        ActiveRecord::Base.connection_pool.with_connection { @app.call(env) }

/Users/daryl/Code/dev/admin-test/lib/connection_pool_management_middleware.rb in call

        ActiveRecord::Base.connection_pool.with_connection { @app.call(env) }

So, appears to have something to do with active record or connection pool management. I have the option use ConnectionPoolManagement on in admin/app.rb (it is set by default in the clean admin-test app though also in my older app I'm upgrading.
What is the expected behavior?
The expected behaviour is that a submitted update gets taken up by the DB
Which versions of Ruby, Padrino, Sinatra, Rack, OS are you using? Did this work in previous versions?
ruby 3.2
Padrino 0.15.2
OSX 13.1 Venture (M1 chipped Macbook)
Gemfile. lock
GEM
remote: https://rubygems.org/
specs:
activemodel (7.0.4)
activesupport (= 7.0.4)
activerecord (7.0.4)
activemodel (= 7.0.4)
activesupport (= 7.0.4)
activesupport (7.0.4)
concurrent-ruby (~> 1.0, >= 1.0.2)
i18n (>= 1.6, < 2)
minitest (>= 5.1)
tzinfo (~> 2.0)
bcrypt (3.1.18)
concurrent-ruby (1.1.10)
daemons (1.4.1)
date (3.3.3)
eventmachine (1.2.7)
haml (5.2.2)
temple (>= 0.8.0)
tilt
i18n (1.12.0)
concurrent-ruby (~> 1.0)
mail (2.8.0)
mini_mime (>= 0.1.1)
net-imap
net-pop
net-smtp
mime-types (3.4.1)
mime-types-data (~> 3.2015)
mime-types-data (3.2022.0105)
mini_mime (1.1.2)
mini_portile2 (2.8.1)
minitest (5.17.0)
moneta (1.1.1)
mustermann (3.0.0)
ruby2_keywords (~> 0.0.1)
net-imap (0.3.4)
date
net-protocol
net-pop (0.1.2)
net-protocol
net-protocol (0.2.1)
timeout
net-smtp (0.3.3)
net-protocol
padrino (0.15.2)
padrino-admin (= 0.15.2)
padrino-cache (= 0.15.2)
padrino-core (= 0.15.2)
padrino-gen (= 0.15.2)
padrino-helpers (= 0.15.2)
padrino-mailer (= 0.15.2)
padrino-support (= 0.15.2)
padrino-admin (0.15.2)
padrino-core (= 0.15.2)
padrino-helpers (= 0.15.2)
padrino-cache (0.15.2)
moneta (~> 1.1.0)
padrino-core (= 0.15.2)
padrino-helpers (= 0.15.2)
padrino-core (0.15.2)
padrino-support (= 0.15.2)
sinatra (>= 2.2.4)
thor (~> 1.0)
padrino-gen (0.15.2)
bundler (>= 1.0, < 3)
padrino-core (= 0.15.2)
padrino-helpers (0.15.2)
i18n (>= 0.6.7, < 2)
padrino-support (= 0.15.2)
tilt (>= 1.4.1, < 3)
padrino-mailer (0.15.2)
mail (~> 2.5)
mime-types (< 4)
padrino-core (= 0.15.2)
padrino-support (0.15.2)
rack (2.2.5)
rack-protection (3.0.5)
rack
rake (13.0.6)
ruby2_keywords (0.0.5)
sinatra (3.0.5)
mustermann (~> 3.0)
rack (~> 2.2, >= 2.2.4)
rack-protection (= 3.0.5)
tilt (~> 2.0)
sqlite3 (1.5.4)
mini_portile2 (~> 2.8.0)
temple (0.9.1)
thin (1.8.1)
daemons (~> 1.0, >= 1.0.9)
eventmachine (~> 1.0, >= 1.0.4)
rack (>= 1, < 3)
thor (1.2.1)
tilt (2.0.11)
timeout (0.3.1)
tzinfo (2.0.5)
concurrent-ruby (~> 1.0)
PLATFORMS
arm64-darwin-22
DEPENDENCIES
activerecord (>= 3.1)
activesupport (>= 3.1)
bcrypt
haml (= 5.2.2)
padrino (= 0.15.2)
rake
sqlite3
thin
BUNDLED WITH
2.4.3

@wakatara I believe ActiveRecord 7.0 replaced update_attributes with update.

Wow that's a pretty major change, we may need to then lock AR to < 7 until the admin module is updated to support either. This wouldn't be a big lift to support though unless there's more breaking changes as we could check which method the object responds to in the admin controller.

It looks like the update and update! methods have been around since ActiveRecord 4.0. It might be ok just to do a straight up replacement. I was wrong, update_attributes was removed in 6.1.

Ah in that case, maybe it's an even easier fix if anyone wants to post a PR re generated admin code admin/controllers/accounts.rb in padrino-admin https://github.com/padrino/padrino-framework/blob/master/padrino-admin/lib/padrino-admin/generators/templates/page/controller.rb.tt

It looks like this might be the place that needs updated: https://github.com/padrino/padrino-framework/blob/dc493e3870cd343f5bfe7edb21248389a5370963/padrino-admin/lib/padrino-admin/generators/orm.rb#L127
I think :activerecord and :minirecord (is this really supported? 😅 ) could be moved to the same line as :datamapper and :ohm.

@jkowens  Yup, you're totally right. AR 7 changed things from update_attributes to update. A simple global search and replace on all the controllers using update_attributes in the app made that work again without any further fuss. Thank you!
I've put a TODO in my GTD app to circle back and fix the generators with a condition for AR 7.0 soon as I get through this upgrade push. Maybe this weekend, if not, next week... =]

I also find the reasons they removed them after advocating them pretty arbitrary, considering the number of gems it probably broke across the multiverse... 8-/
https://github.com/rails/rails/pull/31998

authors: jkowens nesquena wakatara


text:
🛑 Carakas is down

In cc1cc02, Carakas (https://poetry.carakas.be) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Carakas is back up in 162c635 after 53 minutes.

repo: pageon/uptime


text:
Provide test files for conformance testing

It would be much easier to write an importer if there would be some test files available with different important scenarios (like transformations or reusing a mesh with different colors).

Thank you for that comment, I uploaded right now few test files from different sources here: https://github.com/paireks/dotbim/tree/master/test/ExampleFiles
Each test file has it's own .png to check visually if it's ok. All of them are quite simple, but checks various things. I think later it would be great to add some big one e.g. for performance check.

I've tried this one: https://github.com/paireks/dotbim/blob/master/test/ExampleFiles/TestFilesFromC%23/Cubes.bim
The png looks like this:

But in the official viewer it looks really strange:

I think that the rotation value is not correct in that file.

Yeah, you're right, rotation values are probably wrong, I will change this file

I've changed this example already. For rotation checks you can use this example: https://github.com/paireks/dotbim/blob/master/test/ExampleFiles/TestFilesFromGh/BricksRotated.bim

authors: kovacsv paireks

repo: paireks/dotbim


text:
Streamer_login permissions

I feel like the bot should ask for more perms in order to make it function properly. Eg: channel:moderate, user:edit:broadcast (I believe this is for title/game adjustments) - this should make for an overall "easier setup" when first starting with pajbot (then your bot doesn't require the editor role)

duplicate of #450

beat me to it FeelsWeirdMan

repo: pajbot/pajbot


text:
transcription confidence

Would it be possible for this library to add the interface to retrieve the confidence of each token that whisper has generated?
Basically what I would like to have is when using whisper.cpp with the --print-color flag
Maybe if for example the library returned a list with the list of tokens and their confidence?
I'd like to help implement this, I just don't know where to start. If you just give me some suggestions, maybe I can implement it for you and make a pull request
p.s. Thanks for the project!

This is already possible in some form with the current code, but there is no easy-to-use function. We implemented some form of this in https://github.com/transcribee/transcribee/blob/main/worker/transcribee_worker/whisper_transcribe.py
I think the way to go would be to duplicate the Whisper.transcribe function and instead of just joining all words (https://github.com/pajowu/whispercppy/blob/main/src/init.py#L189) extracting the information for the tokens, as done here: https://github.com/transcribee/transcribee/blob/8d3eb008de243fe70e1a9f998b9dd4f1dc8d3eb7/worker/transcribee_worker/whisper_transcribe.py#L69C3-L123

Feel free to open a PR for this

Feel free to open a PR for this

Thank you so much for your quick reply!
These days I was studying to give an exam at the university... so within a few days I can commit to create some code.
I've never used GitHub for collaborations or improving other repositories, so if I mess up with the pull request please bear with me :')
I will use the links you sent me as a cue and try to implement an easy-to-use feature. Thanks for everything! :D

authors: DanielusG pajowu

repo: pajowu/whispercppy


text:
Fix audio example being too complex

The previous audio example contained animation and movement.
IMO all examples should be their own little feature, and not combine the two together (Unless they are a sample game, like pong).

Maybe it would be beneficial to have both examples?

Perhaps it should also show that audio can be "background audio", and "not background audio"?
The reason it allowed for scrolling, is because the more you zoom out, the less you hear the weird man, but the bird stay the same.

@EtienneBruines Ah. I see your point. I'll add those back in, but not the animation or movement.

:+1:

+1 on complexity. Such combo things we could demo in an example game but those small demos should help in writing tutorials.

@EtienneBruines I think we should keep this example as it is. But have a second example with what you previously mentioned.
I'll do this in a separate PR.
Merge when ready.

authors: EtienneBruines matiwinnetou paked

repo: paked/engi


text:
Add stacks automation to central repo

Summary

To implement https://github.com/paketo-buildpacks/rfcs/issues/197 and https://github.com/paketo-buildpacks/stacks/issues/133, the new stacks repositories require new automation.
The automation checked in here is based on my fork of the jammy-tiny-stack repository. Most of the automation included here is already running on the fork.
There are a couple of notable differences between this PR and the automation implemented on the jammy-tiny-stack repo:

There is one Create Release step in the release workflow instead of two. The list of release assets is now constructed before the release step, and accounts for the with- and without-USNs cases.
There are a couple of places where the jammy-tiny-stack automation hard-codes names related to the stack and/or linux distribution. I've added steps that parse this info from the Github repo name. These enforce/expect the same repo naming scheme outlined in the Jammy RFC and Bionic Updates RFC.
The create release and push image workflows use the newly refactored File Issue action in this repo.

Checklist

[x] I have viewed, signed, and submitted the Contributor License Agreement.
[ ] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[ ] I have added an integration test, if necessary.
[ ] I have reviewed the styleguide for guidance on my code quality.
[x] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

Basically, I just need to shift some of our refactors out of the jammy tiny stack and move them here.

@ForestEckhardt agreed that testing would be very useful here. Considering we've already started moving forward with the Jammy base/full stacks, would you be comfortable with adding that testing in a separate PR? I'm thinking that may be the move so that the new repositories can be built with the shared tooling. If not, those repositories will probably just use copies of what Jammy Tiny has anyways, which are untested

The changes here look good to me

@sophiewigmore For sure, could we just get an issue to track that really quickly and then I am good to go.

@fg-j Do you have issues for diff-package-receipts and release-notes as well or do those need to be generated?

There aren't issues for those. I can expand the issue to include coverage for those actions as well.

@fg-j can you also update the github-config repo update-tools workflow to include bumping the stacks-related tools?

authors: ForestEckhardt fg-j sophiewigmore

repo: paketo-buildpacks/github-config


text:
Proposal: Add module SBOM generation to this buildpack

I would like to propose adding SBOM generation for golang modules to this buildpack. I propose to achieve this via the SBOM generation feature in packit (once the API for packit is stabilized).
I would have proposed adding it to the go-mod-vendor buildpack, except I understand that this wouldn't be possible because the go-mod-vendor doesn't write the vendored modules to a layer (because the golang tooling doesn't follow symlinks).
Any concerns with this approach?
@paketo-buildpacks/go-maintainers

I think it would make sense for the go-mod-vendor buildpack to generate the BOM and store it in the Build metadata SBOM (rather than a layer SBOM). I think this makes sense because the go-mod-vendor buildpack is the one responsible for pulling the go modules into the app workspace.

@fg-j and would you then expect the go-build buildpack to write the SBOM files in its layer? Or would you not expect it to be present in a layer at all?

I agree with @fg-j that the SBOM for the modules should appear in the build metadata for the go-mod-vendor buildpack. As for the go-build buildpack, that would have its own SBOM. It appears that syft is capable of determining the packages used to build a go binary. Those SBOMs may have some overlap but would likely be different as the binary would only include those packages that make it into the binary while the go-mod-vendor SBOM might include packages like testing libraries or other build-time dependencies.

This would form part of the overall SBOM work highlighted in https://github.com/paketo-buildpacks/go/issues/524 and would confirm to Paketo RFC0038. The RFC outlines the changes in more detail.

@ryanmoran I've been experimenting with using the syft CLI with Go binaries, and I haven't been able to get it working. I left a comment on this issue where they discuss implementing this feature to scan binaries in OCI images.

Implementing this feature is blocked on platform integration issues.

authors: fg-j robdimsdale ryanmoran

repo: paketo-buildpacks/go-build


text:
Maven dep

Summary
Changes to Detection:

By default, we now pass
By default, we provide three possible plans all of which only provide (one provides just maven, one provides just a built app, one provides maven and a built app)
If a pom.xml file exists, then we add a requires (jdk, syft, maven).

Changes to Build:
Based on what is in the buildplan, the buildpack can now optionally install and optionally build.
If maven is in the buildplan, then the buildpack will attempt to install or validate that Maven is installed and generate a command to run Maven.
This can be done in four ways:

Install Maven Daemon
Install Maven
Validate Maven Wrapper
Validate Maven on $PATH

If jvm-application-package is in the buildplan, then the buildpack will attempt to perform a build with Maven. This uses the command from the previously installed or validated Maven.
Use Cases
This enables four scenarios:

The buildpack installs & runs Maven (or Maven Daemon)
The buildpack runs Maven w/Maven Wrapper
The buildpack just installs Maven (or Maven Daemon)
The buildpack doesn't install Maven or use Maven Wrapper, but just runs Maven (Maven is provided through other means)

For 1.) & 2.) are the classic cases we've been supporting.
For 3.) & 4.) are the new cases that have been requested.
Resolves #159
Resolves #184

@AidanDelaney - FYI

This looks really good.  The maven_manager abstraction feels like the right separation of concerns.

By default, we provide three possible plans all of which only provide

Don't we always still require a JDK?

& 2. are the classic cases we've been supporting.   -- & 4. are the new cases that have been requested.

I think auto numbering messed these points up, not a big deal but it's a very useful summary so good to have it correct if so

By default, we provide three possible plans all of which only provide

Don't we always still require a JDK?

Right now, we contribute three plans always:

Provides maven + Requires jdk
Provides jvm-application-package
Provides jvm-application-package + Provides maven.

The thought is that for the first option, some other buildpack would need to require Maven. Thus, we require jdk so the other buildpack doesn't need to do that.
For two and three, the thought is that you need a pom.xml file & when a pom.xml is found, we automatically require jdk, syft and maven for those build plans. My understanding is that with build plans, the first one that matches will be picked so if a builder extension requires jvm-application-package and also meets the jdk, syft and maven requirements then it would get picked first. If not, then the default buildack option would be pick (i.e. option three, install & build).
Does that sound good?

& 2. are the classic cases we've been supporting.   -- & 4. are the new cases that have been requested.

I think auto numbering messed these points up, not a big deal but it's a very useful summary so good to have it correct if so

Fixed.

Yes it makes sense 👍
My first point wasn't very clear, I just meant to clarify whether plan 1 makes this wording untrue: 'all of which only provide' since there is always a Requires for #1.
Looks good though and the extra tests make the scenarios easier to follow now 🎉

@dmikusa this change broke the pipelines on our end due to the fact that the maven buildpack now detects always, without requiring JDK to be installed. We're building images from a pre-compiled jar file, and now we get the following error with the lates version of java buildpack:
$ pack build --builder paketobuildpacks/builder:base --buildpack gcr.io/paketo-buildpacks/java:latest --path target/demo-1.0.0.jar test-image
Previous image with name "test-image" not found
===> DETECTING
7 of 24 buildpacks participating
paketo-buildpacks/ca-certificates   3.4.0
paketo-buildpacks/bellsoft-liberica 9.7.0
paketo-buildpacks/syft              1.20.0
paketo-buildpacks/maven             6.9.0
paketo-buildpacks/executable-jar    6.5.0
paketo-buildpacks/dist-zip          5.4.0
paketo-buildpacks/spring-boot       5.19.0
===> RESTORING
===> BUILDING

Paketo Buildpack for CA Certificates 3.4.0
  https://github.com/paketo-buildpacks/ca-certificates
  Launch Helper: Contributing to layer
    Creating /layers/paketo-buildpacks_ca-certificates/helper/exec.d/ca-certificates-helper

Paketo Buildpack for BellSoft Liberica 9.7.0
  https://github.com/paketo-buildpacks/bellsoft-liberica
  Build Configuration:
    $BP_JVM_JLINK_ARGS           --no-man-pages --no-header-files --strip-debug --compress=1  configure custom link arguments (--output must be omitted)
    $BP_JVM_JLINK_ENABLED        false                                                        enables running jlink tool to generate custom JRE
    $BP_JVM_TYPE                 JRE                                                          the JVM type - JDK or JRE
    $BP_JVM_VERSION              11                                                           the Java version
  Launch Configuration:
    $BPL_DEBUG_ENABLED           false                                                        enables Java remote debugging support
    $BPL_DEBUG_PORT              8000                                                         configure the remote debugging port
    $BPL_DEBUG_SUSPEND           false                                                        configure whether to suspend execution until a debugger has attached
    $BPL_HEAP_DUMP_PATH                                                                       write heap dumps on error to this path
    $BPL_JAVA_NMT_ENABLED        true                                                         enables Java Native Memory Tracking (NMT)
    $BPL_JAVA_NMT_LEVEL          summary                                                      configure level of NMT, summary or detail
    $BPL_JFR_ARGS                                                                             configure custom Java Flight Recording (JFR) arguments
    $BPL_JFR_ENABLED             false                                                        enables Java Flight Recording (JFR)
    $BPL_JMX_ENABLED             false                                                        enables Java Management Extensions (JMX)
    $BPL_JMX_PORT                5000                                                         configure the JMX port
    $BPL_JVM_HEAD_ROOM           0                                                            the headroom in memory calculation
    $BPL_JVM_LOADED_CLASS_COUNT  35% of classes                                               the number of loaded classes in memory calculation
    $BPL_JVM_THREAD_COUNT        250                                                          the number of threads in memory calculation
    $JAVA_TOOL_OPTIONS                                                                        the JVM launch flags
    Using Java version 11 extracted from MANIFEST.MF
  BellSoft Liberica JRE 11.0.16: Contributing to layer
    Downloading from https://github.com/bell-sw/Liberica/releases/download/11.0.16.1+1/bellsoft-jre11.0.16.1+1-linux-amd64.tar.gz
    Verifying checksum
    Expanding to /layers/paketo-buildpacks_bellsoft-liberica/jre
    Adding 127 container CA certificates to JVM truststore
    Writing env.launch/BPI_APPLICATION_PATH.default
    Writing env.launch/BPI_JVM_CACERTS.default
    Writing env.launch/BPI_JVM_CLASS_COUNT.default
    Writing env.launch/BPI_JVM_SECURITY_PROVIDERS.default
    Writing env.launch/JAVA_HOME.default
    Writing env.launch/JAVA_TOOL_OPTIONS.append
    Writing env.launch/JAVA_TOOL_OPTIONS.delim
    Writing env.launch/MALLOC_ARENA_MAX.default
  Launch Helper: Contributing to layer
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/active-processor-count
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/java-opts
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/jvm-heap
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/link-local-dns
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/memory-calculator
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/security-providers-configurer
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/jmx
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/jfr
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/security-providers-classpath-9
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/debug-9
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/nmt
    Creating /layers/paketo-buildpacks_bellsoft-liberica/helper/exec.d/openssl-certificate-loader
  Java Security Properties: Contributing to layer
    Writing env.launch/JAVA_SECURITY_PROPERTIES.default
    Writing env.launch/JAVA_TOOL_OPTIONS.append
    Writing env.launch/JAVA_TOOL_OPTIONS.delim

Paketo Buildpack for Syft 1.20.0
  https://github.com/paketo-buildpacks/syft
    Downloading from https://github.com/anchore/syft/releases/download/v0.57.0/syft_0.57.0_linux_amd64.tar.gz
    Verifying checksum
    Writing env.build/SYFT_CHECK_FOR_APP_UPDATE.default

Paketo Buildpack for Maven 6.9.0
  https://github.com/paketo-buildpacks/maven
  Build Configuration:
    $BP_MAVEN_BUILD_ARGUMENTS  -Dmaven.test.skip=true --no-transfer-progress package  the arguments to pass to Maven
    $BP_MAVEN_BUILT_ARTIFACT   target/*.[ejw]ar                                       the built application artifact explicitly.  Supersedes $BP_MAVEN_BUILT_MODULE
    $BP_MAVEN_BUILT_MODULE                                                            the module to find application artifact in
    $BP_MAVEN_DAEMON_ENABLED   false                                                  use maven daemon
    $BP_MAVEN_POM_FILE         pom.xml                                                the location of the main pom.xml file, relative to the application root
    $BP_MAVEN_SETTINGS_PATH                                                           the path to a Maven settings file

Paketo Buildpack for Maven 6.9.0
  unable to create application layer
  failed to generate expected metadata
  unable to determine java version
  error executing 'javac -version':
   Combined Output: :
  unable to start PTY
  exec: "javac": executable file not found in $PATH
ERROR: failed to build: exit status 1
ERROR: failed to build: executing lifecycle: failed with status code: 51

Thanks for the report. I thought we'd accounted for that case, but clearly not. We're going to roll this back temporarily. We need to add a bit more logic to the detect.

@pbusko Sorry for the issue, I have PR #189 which should correct this.
If you have a minute to test & give us some feedback, I have a docker image up with this fix. pack build <app-image> --buildpack dmikusa/paketo-java. That'll pull from Docker Hub, it's a build of the standard Paketo Java buildpack but with an advanced build including PR #189.

@dmikusa sorry for late reply, I can confirm that when using dmikusa/paketo-java buildpack, the issue no longer occurs. Maven buildpack doesn't detect anymore.

Excellent! thanks!

authors: AidanDelaney dmikusa pbusko pivotal-david-osullivan

repo: paketo-buildpacks/maven


text:
Accept ProcessFunc into top-level Crawl function

Top-level Crawl signature change
Crawl now accepts a type ProcessFunc func(ctx context.Context, path string, result Finding, version Versions) handler responsible for reporting on individual findings during the crawl.
The ProcessFunc used in the production code is the same reporter that has been previously used, the driver of this change was to produce a friendly framework for testing examples, allowing us to more easily add specific test cases and test against an actual data structure rather than string matching against command output.
crawl.Stats
Also in this change, the top-level Crawl function now passes the crawl.Stats from the generic filesystem crawler to the crawl command, where the summary rendering logic now lives.
Simple summary rendering test
Adds a simple integrations test for the summary printing so that we can ensure we don't break the output in case there are system log queries or workflows based on that specific line.

Thanks @nmiyake 😄 !
I've updated the description to describe the three noteworthy changes I see in the PR. Please to comment further if you feel I should be doing this another way.
Admittedly, the way this was initially thought out and then how fast a few of us moved at the start meant that quite a few components of the codebase ended up with a non-ideal design.
I definitely agree with your statements about ideal state of the repo/design and would like us to tend towards it over time where making those changes isn't too much a detour on the way to solving the issues that we need to to consider the product complete.

Approving on the basis this has addressed the review request to improve the commit message. I'm in agreement that there is too tight coupling right now - almost every PR has to touch identify.go which is a strong suggestion it's doing too much in addition to the comments about unit tests I also agree with.

authors: glynternet hpryce


text:
fix(collector): force update when connection is unstable

Related Issues

Closes #51

Proposed Changes:
This change forces a full update when UpdateFailed exception is detected. If that happens, very likely there is a connectivity error and there is a chance the backend considers the connection with the central unit gone. In that case, it resets last known IDs, causing the integration to not detect any new change as described in #51.
This fix is available in this commit: https://github.com/palazzem/ha-econnect-alarm/pull/68/commits/588082b455c8e005c290dce3b6c66eaf649e70b3
Instead of adding the fix, this PR also refactors entirely how the DataUpdateCoordinator is exposed to the integration, so that now it's a self contained coordinator called AlarmCoordinator. The coordinator is fully tested and a regression test is added to the test suite.
Testing:

Install the latest version that includes this change
Produce updates for 1-2 minutes (e.g. trigger some inputs)
Test 1: disconnect the central unit and reconnect immediately
The integration must be stuck, it should recover within 5 minutes
Produce updates for 1-2 minutes (e.g. trigger some inputs)
Test 2: disconnect the central unit and reconnect after 5-10 minutes
The integration must be stuck, it should recover within 5 minutes

Extra Notes (optional):
n/a
Checklist

[x] Related issues and proposed changes are filled
[x] Tests are defining the correct and expected behavior
[x] Code is well-documented via docstrings

PR has been reverted so that the bugfix can be released in a hotfix. The refactor will be separated from the hotfix.

repo: palazzem/ha-econnect-alarm


text:
Initialization of behaviors and events

I've been thinking about how best to initialize behaviors and events.
Goals:

Initialization should only be allowed to happen once
It should be easy to find where in the view a thing is being initialized

This is what we currently have. Initialization can be found by searching for "name.def".
{click: btnClick.def} = button("Click me")

This one looks very non-magical. One would have to find initialization locations by searching for ": name".
button("Click me", {on: {click: btnClick})

This one also has no magic. The def function (or whatever it should be called) extracts events from the component.
def({click: btnClick}, button("Click me")

In this one the events list specifies which events to create. But it doesn't work, because the result of the expression whould not be the component but instead the array.
[btnClick.def] = button("Click me", {events: ["click"]})

I like the idea of it being non-magical and prefer:
button("Click me", {on: {click: btnClick})

this would work well if we want to implement a HyperScript-like functions where you describe all the properties and settings in an object.
button("click me", {
  on:{
    click: btnClick
  },
  style: {
    paddingLeft: "5px"
  },
  attributes: {
    disabled
  }
}

Good point. It will also work smoothly with JSX which none of the others will. I think we'll pick that one then.
Also, to ensure that a behavior/event can only be hooked into one component, I we could do this: Instead of having a push method, the behaviors returned by declareBehaviors could have a getPush method that returns a push function and throws an error if it is called more than once.

authors: limemloh paldepind

repo: paldepind/hareactive

license: mit


text:
iPhone 8 | 15.1 | Bug

Describe the bug
When the device is idle or in sleep mode the device panics.
Expected behavior
I expected for the jailbreak to work instead the device panics.
Screenshots
No screenshots.
Info:

iDevice's version: 15.1
Computer OS and version: macOS 12.5.1
Command ran: ./palera1n.sh --tweaks 15.1

Additional context
None.
Debug log
No logs are needed because the device is already jailbroken.

I updated to 1.1.1 palera1n now the issue is fixed!

unbale to conect device

![Uploading 194777246...]

unbale to conect device

This is NOT a palera1n issue + create your own one instead of commenting under other ones

please bro, make this issue under MY REPO

Just install iNoSleep tweak then the issue should be fixed.

authors: KhaledCP RavanGami mineLdiver verygenericname


text:
Pogo issue

I Install Pogo success and Sileo too, but when i turn on passcode ( i turn off before for run palra1n) , i got black screen and must hard reset to reboot again, when reboot done, Pogo( Tips app ) crashed and Sileo too. I cant open it or do anything, i try again 2-3 times still got it.
Phone: 7 Plus GSM (9,4) , IOS 15.6 RC

passcode must not be enabled when booted from DFU mode

passcode must not be enabled when booted from DFU mode, and it must stay that way until the device is rebooted

ok i got it, but i start from normal mode, not DFU

palera1n boots the device from DFU mode so you did boot from DFU mode

palera1n boots the device from DFU mode so you did boot from DFU mode

yes, i try start from DFU mode, still got same issue, when i turn on passcode, bc i want to lock my phone , got black screen.

to lock your phone, reboot first

to lock your phone, reboot first then do not jailbreak

:)

to lock your phone, reboot first then do not jailbreak

so anytime if i turn back on passcode, rootless will gone right and i cant use pogo or trollstore right ?

yes


text:
[Question] Can i use a select for user prompt.

hi,
I want to use a select prompt like rawselect with questionary package but it's doesn't work.
With click can i use a select or an other thing like this, or we can only use prompting in documentation?
Thx for your amazing work.
Regards

Please use Stack Overflow for questions about your own code. This tracker is for issues related to the project itself. Be sure to include a minimal, complete, and verifiable example.

authors: davidism mBouamama

repo: pallets/click


text:
Fix decorator typing with _Decorator type alias

_Decorator[FC] is identical to t.Callable[[FC], FC]. However, mypy currently reads the first type incorrectly and supports the second one fully.
This fix will make mypy checking work correctly on click decorators, and should have no negative impact on other type checkers because the types are effectively "the same".

fixes #2558

I plan to open a bug report against mypy to ask about this issue. It may be a duplicate (https://github.com/python/mypy/issues/13250 ?), but we'll have a thread to pull on there to figure out why this isn't supported when there doesn't appear to be a meaningful difference between the two types.
Checklist:

[ ] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.

I haven't added tests because any mypy testing will require some kind of new framework for testing types.
I think this would be valuable and not hard (e.g. here's some prior art in marshmallow which I helped setup), but it's beyond the scope of a small typing fix.
Instead, I tested mypy v1.4.1 (latest) before and after this change on the following small sample:
from click import option

def foo(a: int) -> str:
    return str(a)

reveal_type(option)
foo = option()(foo)
reveal_type(foo)

Before the change:
$ mypy click_example.py
click_example.py:8: note: Revealed type is "def [FC <: Union[def (*Any, **Any) -> Any, click.core.Command]] (*param_decls: builtins.str, *, cls: Union[Type[click.core.Option], None] =, **attrs: Any) -> def (FC`-1) -> FC`-1"
click_example.py:9: error: Argument 1 has incompatible type "Callable[[int], str]"; expected <nothing>  [arg-type]
click_example.py:10: note: Revealed type is "<nothing>"
Found 1 error in 1 file (checked 1 source file)

After the change:
$ mypy click_example.py
click_example.py:8: note: Revealed type is "def (*param_decls: builtins.str, *, cls: Union[Type[click.core.Option], None] =, **attrs: Any) -> def [FC <: Union[def (*Any, **Any) -> Any, click.core.Command]] (FC`-1) -> FC`-1"
click_example.py:10: note: Revealed type is "def (a: builtins.int) -> builtins.str"
Success: no issues found in 1 source file

[x] (N/A) Add or update relevant docs, in the docs folder and in code.

[x] Add an entry in CHANGES.rst summarizing the change and linking to the issue.

I added a changelog section for 8.1.5 since this is the first change after 8.1.4. I'm happy to make tweaks and changes if this was not appropriate.

[x] (N/A) Add .. versionchanged:: entries in any relevant code docs.
[x] Run pre-commit hooks and fix any issues.
[x] Run pytest and tox, no tests failed.

No need to file a separate mypy bug. I'm pretty sure this is https://github.com/python/mypy/issues/13449 , and I've left a comment there to hopefully engage the maintainers there.

Thanks for working on this and the good writeup. Looks like #2562 fixes the issue more broadly. Can you check that as well before I close this one, just in case.

authors: davidism sirosen


text:
Clarified the docstring in method Flask.preprocess_request.

The doc now clearly states that the method invokes two set of hook
functions, and how these are filtered before execution.

Respectfully ping :)

Is this PR stating the current docs are out of date or incorrect? I find the previous docs more concise and easier to follow.
For example, when the new version of the doc says the hooks "should be invoked", does that mean the dev has the responsibility of invoking it?

Thanks for looking into this. I found the wording a little verbose and awkward, so I improved it in #2258 as well as making some changes to related docs.

authors: AvivC davidism joequery

repo: pallets/flask


text:
export names with all

Export package level exports using __all__ https://docs.python.org/3/tutorial/modules.html#importing-from-a-package
Checklist:

[x] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
[x] Add or update relevant docs, in the docs folder and in code.
[x] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
[x] Add .. versionchanged:: entries in any relevant code docs.
[x] Run pre-commit hooks and fix any issues.
[x] Run pytest and tox, no tests failed.

Thanks, but we don't do this.

@davidism Any reason for not accepting this patch ?


text:
feat: make label required, add aria-labelledby attribute, add hideLabel option

Our current label/input implementation makes it easy to break accessibility standards without warning by not including a label for inputs. This PR address that by:

Makes label prop required so that consumers can not break accessibility standards without warnings
adds hideLabel prop to allow for users who want to visually hide the label, but still provide an input label for assistive technology
Adds aria-labelledby attribute to inputs for assistive technology

Will update to point to develop once select-input-tests get's merged.

repo: palmetto/palmetto-components


text:
WIP Implement a solana/anchor_lang version of compass

https://github.com/palomachain/paloma/issues/448
Background
A solana/anchor_lang version of compass
Todo

[ ] Some program invocation errors around #[Accounts] structs, which require payer/init annotation
[ ] Cross-program invocation for very specific contracts seems straightforward, for arbitrary contracts I will need to consult an expert
[ ] (optional?) Integrate anchor's js deploy framework

Testing completed

[ ] tbd
[ ] Deploy to solana and invoke other contracts

Can reopen if we get to it.

repo: palomachain/paloma-rs


text:
numpy 1.25.0 incompatible with stubs

Had a CI failure when we test the installed stubs and numpy 1.25.0 gets installed, where mypy complained.
Needs investigation.

Poetry doesn't let you install numpy 1.25.0 as it requires python >=3.9 (which is incompatible since pandas-stubs is also possible with 3.8).
Using numpy 1.25.0 (on python >=3.9) triggers some new warnings:

FAILED tests/test_io.py::test_hdfstore - DeprecationWarning: alltrue is deprecated as of NumPy 1.25.0, and will be removed in NumPy 2.0. Please use all instead.
FAILED tests/test_io.py::test_read_hdf_iterator - UserWarning: problems loading leaf /df/table::
FAILED tests/test_io.py::test_hdf_context_manager - UserWarning: problems loading leaf /df/table::

I would have thought that a project like Numpy would support Python 3.8 until it's actual EOL in about a year. Seems odd, unless it's a Poetry thing.

I would have thought that a project like Numpy would support Python 3.8 until it's actual EOL in about a year. Seems odd, unless it's a Poetry thing.

https://numpy.org/neps/nep-0029-deprecation_policy.html#support-table Pandas follows Numpy's policy

authors: Dr-Irv gandhis1 twoertwein

repo: pandas-dev/pandas-stubs