Storing project metadata in pyproject.toml, hatchling build backend, hatch workflow, refactor rpm specfile with latest Fedora packaging guidelines

Fixes #2145.
What is included:

Removed setup.py, project's metadata are stored in pyproject.toml (PEP-621)
Using Hatch framework for builds, venv management, scripts
Using hatchling build backend
Rewritten tmt.spec file to comply with Fedora packaging guidelines.
Using pyproject-rpm-macros where able.

moving to optional extras packages (metapackages that only specify dependencies for extra features)

VCS versioning (hatch-vcs plugin)
man page being built using sphinx manpage plugin (full documentation instead of just README)
Python-based scripts moved from Makefile to hatch envs
Removing bin directory

moving cli import logic to main.py
shell completion can be installed by individuals using tmt setup completion commands and does not need to be packaged

TODO:

[ ] %pyproject_extras_subpkg does not support Obsoletes, Requires .
See comment https://github.com/teemtee/tmt/pull/2209#issuecomment-1662439432
Needs consensus whether tmt package can obsolete plugin packages.
[X] New version of hatchling for EPEL9 is in testing repo. Until it will be accepted, el9 builds will fail (unless testing repo is enbled).
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-d689ae7c5f
[ ] Build & Publish release action
hatch build (docs) will create source tar and wheel in dist dir:[mhoyer@x1 tmt]$ ls dist/
tmt-1.25.0.dev0-py3-none-any.whl  tmt-1.25.0.dev0.tar.gz

hatch publish command can be used for uploading built files to pypi, however there is the new Trusted Publisher mechanism. I imagine the CI should look like 1) install hatch, 2) hatch build 3) run pypi-publish github action.
[ ] Update documentation

contribute doc
instructions for build, publish?

[X] Fix remaining test failures
[ ] Internal plugins?

FYI the description for the 'extras' is autogenerated. For example python3-tmt+convert package looks like:
Installed Packages
Name         : python3-tmt+convert
Version      : 1.25.0.dev0
Release      : 1.fc37
Architecture : noarch
Size         : 19 k
Source       : tmt-1.25.0.dev0-1.fc37.src.rpm
Repository   : @System
From repo    : @commandline
Summary      : Metapackage for python3-tmt: convert extras
URL          : https://github.com/teemtee/tmt
License      : MIT
Description  : This is a metapackage bringing in convert extras requires for python3-tmt.
             : It makes sure the dependencies are installed.

I'll read it better later however how will 'release' wrt version? We can't have .dev there.

Currently, the version is being bumped by Makefile script.

Well, to explain the process.
For Release which gets uploaded to PyPI and packaged in Fedora updates: Follow https://tmt.readthedocs.io/en/stable/contribute.html#release which includes manual step of changing the Release field in the tmt.spec file.
For packit builds for PR or for main branch packit the Makefiles 'make bump2dev' is called which moves the .y to the next one and add .dev suffix (hence all packit builds are the (y+1).dev version so it is clear from logs when something fails).
I'd say that requirements for CI builds are that no version manipulation should happen directly by developer as it is super easy to forget.
There is bunch of manual work during the release itself so one more step (changing the release) doesn't hurt.

Currently, the version is being bumped by Makefile script.

Well, to explain the process.
For Release which gets uploaded to PyPI and packaged in Fedora updates: Follow https://tmt.readthedocs.io/en/stable/contribute.html#release which includes manual step of changing the Release field in the tmt.spec file.

Looking at the doc, I think some parts could be streamlined.

Use git log --oneline --no-decorate x.y-1.. to generate the changelog

Any chance this can be replaced by %autochangelog?

Add a Release tmt-x.y.0 commit with the specfile update
'bump2dev'
sed -i $(REPLACE_VERSION) tmt/init.py
VERSION = $(shell grep ^Version tmt.spec | sed 's/.* //')

Instead of using specfile as source of truth, why not use the project's version instead?
You can bump the y+1 by running hatch version minor
Bump dev by running hatch version dev
Get current version by running hatch version and use the output in specfile.
There is also hatch-vcs plugin.
This might not work well with %pypi_source macro, though that is relevant only if you decide to use pypi as source (probably better to keep pointing to github?).

Create a source tarball using the make tarball command

hatch build
then copy dist/tmt*tar.gz to rpmbuild/SOURCES/
Looking at Makefile:

Run the test suite, optionally with coverage

These can be moved to [tool.hatch.envs.default.scripts]

podman build -t tmt --squash -f ./containers/Dockerfile.mini .
podman build -t tmt-all --squash -f ./containers/Dockerfile.full .

Surely these should be called Containerfile :)

Looking at the current %changelog, it seems like it's exactly what %autochangelog would do, no?
https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs
Guidelines also mention that it 'should' be used:

The changelog should be generated automatically from git commit logs using the %autochangelog macro

Looking at the doc, I think some parts could be streamlined.

If only we can trust that all PR before the release are correctly formatted etc.

Use git log --oneline --no-decorate x.y-1.. to generate the changelog

Any chance this can be replaced by %autochangelog?

A bit of cleanup is necessary if the commit message wasn't good enough OR the (#PR_ID) got sneaked from merge/squash via webui
More painful is checking AUTHORS as many of us are using personal github/email accounts and I'm not sure we should post the 'address book' publicly.

Add a Release tmt-x.y.0 commit with the specfile update
'bump2dev'
sed -i $(REPLACE_VERSION) tmt/init.py
VERSION = $(shell grep ^Version tmt.spec | sed 's/.* //')

Instead of using specfile as source of truth, why not use the project's version instead? You can bump the y+1 by running hatch version minor Bump dev by running hatch version dev Get current version by running hatch version and use the output in specfile.

As long as packit and release action do the right thing all is possible.

It's a pain, but I'm learning a lot and think I'm getting somewhere.
Few notes:

vcs versioning is actually pretty nice

use SETUPTOOLS_SCM_PRETEND_VERSION env var for specific version.
epel9 hatchling version is too low for it to work properly with pyproject rpm-macros - opened an RFE bz

Makefile is gone, added relevant hatch scripts

I've tried to do multiple hatch environments, but ultimately everything is depending on everything and I stuck with default and test(which inherits default). Could be improved I think.

bin/ directory is deleted

the tmt executable redundant, the import logic is moved to tmt/main.py
the completion file I think also doesn't make sense to include when tmt setup completion exists - it is one more thing to manually maintain, while users still have to include it in .bashrc as far as I can tell

Not building manpage

can be done, but too painful - I opened specfiles of a few random python projects and none of them includes manpage?

I think the pyproject.toml and specfile are pretty neat like this, but there is still work to be done on tests and documentation.
Please let me know how you feel about the changes, especially the rpm naming, metapackages, no manpage and hatch environments/scripts.

...

Makefile is gone, added relevant hatch scripts

I've tried to do multiple hatch environments, but ultimately everything is depending on everything and I stuck with default and test(which inherits default). Could be improved I think.

I for one would prefer keeping Makefile around, I would even make it the main entry point. TBH, it's mostly about the scripts, most of pyproject.toml scripts feel too shoehorned into the Python world. Feels like going the opposite direction, trying to bend Python to do things shell and make would handle better.
Some targets can be just a facade for hatch scripts, make install calling hatch and nothing else, perfect; make test is present pretty much everywhere, wanna run tests, go for make test or make check, works for GNU tools and kernel too :) Some could do more work surrounding the actual packaging, like make docs... I'm not 100 % sure about this, maybe I need more reasoning to grasp hatch better, but as it is, in my mind make seems to be better fitted for the main entry point of tmt repository actions, and what's left is finding a balance between responsibilities of hatch and make... We never let Poetry handle everything, we have a Makefile which handles the building of Docker images and it has very nice help and groups of targets... Anyway :)

@happz Thanks for the feedback!

I for one would prefer keeping Makefile around, I would even make it the main entry point. TBH, it's mostly about the scripts, most of pyproject.toml scripts feel too shoehorned into the Python world. Feels like going the opposite direction, trying to bend Python to do things shell and make would handle better.

First of all, it's about virtual environment management. By "hatch scripts", I mean "hatch env scripts" - the script is executed in specific venv, with specific dependencies(and version control), so it's the same for all developers. The envs are nicely configurable - some scripts doesn't need the project to be installed before running scripts, some scripts doesn't need venv at all, you can include/exclude env vars, define pre-install/post-install commands.
Also, hatch is made to be modular - for example there is hatch-containers, which allows you to do:
[tool.hatch.envs.<ENV_NAME>]
type = "container"

to run it's scripts in containers. So let's say you can run tests on fresh images of all supported systems, or run destructive tests...
I'm also using:
[[tool.hatch.envs.test.matrix]]
python = ["3.8", "3.11"]

so the tests are being run on minimal supported Python version as well as maximal. (this doesn't require plugin)
When you say shoehorned I think it goes both ways:
make tests running 'python3 -m pytest' is shoehorning python things into bash/make thing and is inferior from my pov, while running non-python things trough hatch is not great and the only point is to have them all in one place with same syntax.

Some targets can be just a facade for hatch scripts, make install calling hatch and nothing else.

Sounds good to me.

make test or make check, works for GNU tools and kernel too :)

So does sending patchfiles to mailing lists, if you know what I mean..

hatch-vcs plugin - epel9 hatchling version is too low for it to work properly with pyproject rpm-macros

Worked on this today: https://bugzilla.redhat.com/show_bug.cgi?id=2158497
If it won't get accepted, the workaround is not too bad - adding -w flag to %pyproject_buildrequires and explicitly specifying license file.

+1 to happz about makefile, it should stay (make srpm, make rpm, make clean ...)
I don't understand the " Is renaming from tmt to python3-tmt ok? (following packaging guidelines)" point, I've skimmed the guidelines but 'tmt' is primary 'tmt' binary. I just happens to be programmed in Python. The component name in src.fedora is 'tmt' as well. Why should it be renamed?

I don't understand the " Is renaming from tmt to python3-tmt ok? (following packaging guidelines)" point, I've skimmed the guidelines but 'tmt' is primary 'tmt' binary. I just happens to be programmed in Python. The component name in src.fedora is 'tmt' as well. Why should it be renamed?

My bad for not describing it well.
One thing is that there are currently a 'tmt' and 'python-tmt' packages, while I believe it should only be one package.
Then there are the 'extras', which I think should be packaged differently.

Edit: 'man' page is also something we should ship.
What should be the format then? just readme, manpage for each command (as generated by click-man) or full documentation in one man file as can be generated with sphinx?

I don't understand the " Is renaming from tmt to python3-tmt ok? (following packaging guidelines)" point, I've skimmed the guidelines but 'tmt' is primary 'tmt' binary. I just happens to be programmed in Python. The component name in src.fedora is 'tmt' as well. Why should it be renamed?

My bad for not describing it well. One thing is that there are currently a 'tmt' and 'python-tmt' packages, while I believe it should only be one package.

Aren't we  https://docs.fedoraproject.org/en-US/packaging-guidelines/#_mixed_use_packages ?
IIRC we can continue to have the status quo.

Then there are the 'extras', which I think should be packaged differently.

Yep, those would be nice to have separated and allow user to install only what they need.

What should be the format then? just readme, manpage for each command (as generated by click-man) or full documentation in one man file as can be generated with sphinx?

If I can dream :) many man pages - probably per 'plugin'? (e.g. if you install tmt-STEP-PLUGIN you gain those man pages). But for now I'd say that packaging readme into man page AND providing (not sure if we do it now) whole html documentation as subpackage might be enough).

Aren't we https://docs.fedoraproject.org/en-US/packaging-guidelines/#_mixed_use_packages ?
IIRC we can continue to have the status quo.

hmm, yeah I misread the doc. That makes things easier :)
There is also https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_application_naming
I'm still not clear about if and how 'tmt' and 'python-tmt' should be split though.
Looking at the doc - what exactly are "virtual provides"?:
"Consider adding a virtual provide according to  above (e.g. python3-PROJECTNAME), if it would help users find the package."

I'm still not clear about if and how 'tmt' and 'python-tmt' should be split though.

Quite difficult for sure. All library usages I know about need just Tree and Test/Plan/Story. I suspect that hardware parsing (once available) will be another useful part of tmt to use in 3rd parties. For other tmt parts I don't see use case where having install 'tmt cli' would be a huge annoyance.

Looking at the doc - what exactly are "virtual provides"?: "Consider adding a virtual provide according to above (e.g. python3-PROJECTNAME), if it would help users find the package."

Can't find good definition, but I'd say that it is just explicit provide in the spec: eg if we rename to 'tmt' but have  Provides: python3-tmt = %{version}-%{release} then dnf install python3-tmt will install 'tmt' even though no such package as 'python3-tmt' exists any more.

I'm still not clear about if and how 'tmt' and 'python-tmt' should be split though.

Quite difficult for sure. All library usages I know about need just Tree and Test/Plan/Story. I suspect that hardware parsing (once available) will be another useful part of tmt to use in 3rd parties. For other tmt parts I don't see use case where having install 'tmt cli' would be a huge annoyance.

To quote the guidelines:
"A major goal for Python packaging in Fedora is to harmonize with the wider Python ecosystem".
"When software is split into several subpackages, it is OK to only ship metadata in one built RPM. In this case, consider working with upstream to also split the upstream project."
Tells me that if there is a need to split the codebase into multiple parts, it should be done in pyproject.toml, not just rpm specfile.

Tells me that if there is a need to split the codebase into multiple parts, it should be done in pyproject.toml, not just rpm specfile.

That is what was attempted in setup.py, isn't it?
We just don't have it 1:1 which is something should change.
IMO the original idea was that 'pip install tmt' or 'dnf install tmt' install usable tmt without too many dependencies.
If one needs more plugins they install it.

Tells me that if there is a need to split the codebase into multiple parts, it should be done in pyproject.toml, not just rpm specfile.

That is what was attempted in setup.py, isn't it? We just don't have it 1:1 which is something should change.

To be clear, I'm talking about splitting tmt as in cli and python-tmt as in library. This is not being done in setup.py, unless I'm mising something

IMO the original idea was that 'pip install tmt' or 'dnf install tmt' install usable tmt without too many dependencies. If one needs more plugins they install it.

That is clear. I'm doing the extra dependencies here with "pyproject_extras_subpkg" macros.
I don't however have any experience with plugins. Note: entry points can be specified in pyproject.toml
If the project is going to be split into two cli/lib packages, I assume it would mean having two packages on pypi, one with optional extras, because if you want to have it in one package, but split lib and cli, you could only specify cli to be optional extra of the lib (i.e. lib is always hard dependency of cli). Or am I missing something?

Let's stop for a bit. What is the benefit of the split in pypi for us? Is it worth time?

Well, we want pypi:rpm parity and currently it's not there, so it's either one additional package in pypi or 'merge' tmt and python-tmt into one rpm.
It should be pretty easy to split it in pyproject.toml and rely on rpm-macros in specfile.
I don't know what is the best way to go. My only opinion is that if this PR will be accepted, it is a good opportunity to "do it right".

Let's stop for a bit. What is the benefit of the split in pypi for us? Is it worth time?

Well, we want pypi:rpm parity and currently it's not there, so it's either one additional package in pypi or 'merge' tmt and python-tmt into one rpm.

How well play single git with more pypi projects? Out-of-tree plugins is something I'd prefer to avoid if possible.

It should be pretty easy to split it in pyproject.toml and rely on rpm-macros in specfile.
I don't know what is the best way to go. My only opinion is that if this PR will be accepted, it is a good opportunity to "do it right".

Definitely.

but that would probably not help much? Maybe it's worth asking some experienced Python project packager(s)...

If you could spare some time, please: @hroncok @frenzymadness  @hrnciar
What can/should we do?

This is a very long conversation. Could you please be a bit more specific about what you want to ask us for? No, it is not possible to have a single pyproject.toml for multiple Python packages. What do you hope to achieve by the split?

This is a very long conversation. Could you please be a bit more specific about what you want to ask us for? No, it is not possible to have a single pyproject.toml for multiple Python packages. What do you hope to achieve by the split?

TL;DR:
tmt is dropping c8s builds, i.e. Python 3.6 and can therefore get rid of various workarounds, as well as update the metadata by following PEP-621 and Fedora packaging guidelines.
The guidelines state that we should aim for parity between the pypi and rpms, and take advantage of pyproject-rpm-macros, however, tmt is currently building 'tmt' (cli) and 'python-tmt' (library) rpms, which is currently not being done in the setup.py as is.
python-tmt lib is afaik not being used by any package other than tmt itself, but based on the previous comment, that might change in the future.
So, the question is whether there should be two packages and if yes, how to approach it.

So, the question is whether there should be two packages

There is no should rule here. Do you want it o be 2 packages or 1 package? For what benefit?

and if yes, how to approach it.

The spirit of the PyPI parity rule is more or less: if you want 2 RPMs, make it 2 packages on PyPI. (Or, in some situations, use extras -- but that's not suitable here as far as I see, so I will not consider it here.)
However, If you try to build 2 packages on PyPI from one single git repository, perhaps it's because you have a hammer, and everything you see starts resembling a nail. I.e. I'd say if it's good in one repo, it's probably good in one RPM.

The current specfile in this PR looks like it abides to the rules. There is no tmt vs python-tmt split and I don't think it was ever needed. Consider adding %py_provides python3-tmt to preserve backwards compatibility and to follow the "all packages with importable Python modules should provide python3-<name of the module>. You should probably also Obsolete all the no-longer-existing packages to preserve the upgrade path.

The current specfile in this PR looks like it abides to the rules. There is no tmt vs python-tmt split and I don't think it was ever needed. Consider adding %py_provides python3-tmt to preserve backwards compatibility and to follow the "all packages with importable Python modules should provide python3-<name of the module>" guideline. You should probably also Obsolete all the no-longer-existing packages to preserve the upgrade path.

Huge thanks for the review @hroncok.
I'm glad the route of having tmt, %py_provides python3-tmt and '%pyproject_extras_subpkg is valid, as it made most sense to me, but wasn't sure if valid.

We could add an API to %pyproject_extras_subpkg to specify custom Obsoletes, Requires, etc., but I am afraid it could easily grow into a monstrosity 🤔

I didn't want to explicitly declare packages just to be able to use Obsoletes. Is it ok if the core package obsoletes the previous plugin packages?
Dependencies resolved.
========================================================================================================================================================
 Package                                Architecture          Version                                                 Repository                   Size
========================================================================================================================================================
Installing:
 tmt+all                                noarch                1.26.1.dev10+g74e41aa3.d20230802-1.fc38                 @commandline                 50 k
 tmt+export-polarion                    noarch                1.26.1.dev10+g74e41aa3.d20230802-1.fc38                 @commandline                 50 k
 tmt+provision-beaker                   noarch                1.26.1.dev10+g74e41aa3.d20230802-1.fc38                 @commandline                 57 k
     replacing  tmt-provision-beaker.noarch 1.25.0-1.fc38
 tmt+provision-container                noarch                1.26.1.dev10+g74e41aa3.d20230802-1.fc38                 @commandline                 50 k
     replacing  tmt-provision-container.noarch 1.25.0-1.fc38
 tmt+provision-virtual                  noarch                1.26.1.dev10+g74e41aa3.d20230802-1.fc38                 @commandline                 50 k
     replacing  tmt-provision-virtual.noarch 1.25.0-1.fc38
 tmt+report-junit                       noarch                1.26.1.dev10+g74e41aa3.d20230802-1.fc38                 @commandline                 50 k
 tmt+report-polarion                    noarch                1.26.1.dev10+g74e41aa3.d20230802-1.fc38                 @commandline                 50 k
 tmt+test-convert                       noarch                1.26.1.dev10+g74e41aa3.d20230802-1.fc38                 @commandline                 50 k
Upgrading:
 tmt                                    noarch                1.26.1.dev10+g74e41aa3.d20230802-1.fc38                 @commandline                675 k
     replacing  python3-tmt.noarch 1.25.0-1.fc38
     replacing  tmt-all.noarch 1.25.0-1.fc38
     replacing  tmt-report-html.noarch 1.25.0-1.fc38
     replacing  tmt-report-junit.noarch 1.25.0-1.fc38
     replacing  tmt-report-polarion.noarch 1.25.0-1.fc38
     replacing  tmt-report-reportportal.noarch 1.25.0-1.fc38
     replacing  tmt-test-convert.noarch 1.25.0-1.fc38

Transaction Summary
========================================================================================================================================================
Install  8 Packages
Upgrade  1 Package

Total size: 1.1 M

One thing I don't love is I had to declare empty extras (they have only non-python rpm deps) in pyproject to make the macros work.
provision-virtual = []
provision-container = []

Is it ok if the core package obsoletes the previous plugin packages?

That means users who had the plugins installed won't have them anymore after they upgarde. So I don't think it's ideal.
Empty extras are OKish I guess. They might get Python requirements in the future etc.

That means users who had the plugins installed won't have them anymore after they upgarde. So I don't think it's ideal.

Not ideal, but not using the %pyproject_extras_subpkg would mean maintaining the extras in two places and the tmt.spec file would be like triple the size.  I do hope there is a better way.

Going back to man pages discussion..

What should be the format then? just readme, manpage for each command (as generated by click-man) or full documentation in one man file as can be generated with sphinx?

If I can dream :) many man pages - probably per 'plugin'? (e.g. if you install tmt-STEP-PLUGIN you gain those man pages).

Big part of this PR is usage of 'optional extras' instead of subpackages, or plugins. The idea of having a manpage per 'plugin' doesn't really work well with it.
I think it's better to have all the documentation present even if the optional dependencies are not installed anyway. If a user tries to run something they read in man and for which they don't have required dependencies, they would get a error message prompting them to install needed metapackage.
That said, click-man does generate many man pages (per command). Not convinced it is the way to go myself, but worth mentioning.

But for now I'd say that packaging readme into man page AND providing (not sure if we do it now) whole html documentation as subpackage might be enough).

Currently it's just readme with different header as far as I can tell. Note that, README.rst and examples dir are listed in %doc
Fwiw, I like using the sphinx build approach over just converting README to man, simply from usability perspective.
Anything more complicated is best left to other PR? Perhaps one that would use markdown and github pages instead of rst and readthedocs :duck:

Sorry guys, I'm not able to dive into all details but would like to share at least some quick questions which pop up...

Storing project metadata in pyproject.toml, hatchling build backend, hatch workflow, refactor rpm specfile with latest Fedora packaging guidelines

Aren't we trying to change a little bit too much in just a single pull request? Wouldn't it be better to go one step at a time? Or is everything so much interconnected that it's not possible?
Could we keep it simple to install the minimal tmt package?  Wouldn't it be possible to keep the old dash-only names?
I'd say python3-tmt package still could be useful: For example explore available tmt tests from a python script. Use this in some minimal container image, installing just the very minimal set of dependencies. What is the motivation to drop it? And do we really want to do this?
Subpackages do not contain relevant module files. Which kind of does not make sense to me as the plugins are detected, are shown in the list of supported methods but cannot work because the dependencies are not installed:
# dnf remove -y tmt+provision-virtual
# tmt run provision --help
Usage: tmt run provision [OPTIONS]

  Provision an environment for testing or use localhost.

  Supported methods (virtual by default):

  artemis .............. Provision guest using Artemis backend
  connect .............. Connect to a provisioned guest using ssh
  local ................ Use local host for test execution
  beaker ............... Provision guest on Beaker system using mrack
  container ............ Create a new container using podman
  virtual.testcloud .... Local virtual machine using testcloud

I believe this could be quite confusing to users.

Storing project metadata in pyproject.toml, hatchling build backend, hatch workflow, refactor rpm specfile with latest Fedora packaging guidelines

Aren't we trying to change a little bit too much in just a single pull request? Wouldn't it be better to go one step at a time? Or is everything so much interconnected that it's not possible?

Pretty much interconnected, but some parts could be cut, like man page or vcs versioning.

Could we keep it simple to install the minimal tmt package? And not install everything unless really needed?

Of course, my bad for not actually trying to install it from repo. This is caused by dnf installing Recommends weak deps by default. I'll remove it.

Is the package renaming unavoidable? Wouldn't it be possible to keep the old dash-only names?

See https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Extras
My point of view is that it's better to do it now and perhaps cause a minor inconvenience, then live forever in a "workaround world" and that it's really nice to be able to rely on pyproject-rpm-macros as much to have single source of truth as opposed to keep maintaining package metadata in two files.

I'd say python3-tmt package still could be useful: For example explore available tmt tests from a python script. Use this in some minimal container image, installing just the very minimal set of dependencies. What is the motivation to drop it? And do we really want to do this?

Talked about this above, see Miro's last comment
To re-iterate: If you want to be compliant with the packaging rules and have parity with pypi, it means either this or build two packages in pypi.
So I did some testing with fedora-latest image by running dnf install python3-tmt
PR#1316 (merged today) copr repo:
Total download size: 14 M
Installed size: 62 M

This PR:
Total download size: 13 M
Installed size: 55 M

What is the advantage of building two packages instead of one then?

Subpackages do not contain relevant module files. Which kind of does not make sense to me as the plugins are detected, are shown in the list of supported methods but cannot work because the dependencies are not installed:
# dnf remove -y tmt+provision-virtual
# tmt run provision --help
Usage: tmt run provision [OPTIONS]

  Provision an environment for testing or use localhost.

  Supported methods (virtual by default):

  artemis .............. Provision guest using Artemis backend
  connect .............. Connect to a provisioned guest using ssh
  local ................ Use local host for test execution
  beaker ............... Provision guest on Beaker system using mrack
  container ............ Create a new container using podman
  virtual.testcloud .... Local virtual machine using testcloud

I believe this could be quite confusing to users.

Thanks for pointing that out. This can definitely be improved, but I was hoping for some guidance about how to approach this.
In my opinion, keeping parity with pypi and complying with packaging guidelines is important for multiple reasons, incl. future-proofing.
If it would be up to me, I'd always list all the supported methods regardless of dependencies being installed or not, and let users know they need optional extras in the cli, documentation and when they try to run something for which they don't have necessary deps installed.
Other way to look at it is that the current pypi version also works this way, and that is for example the only way to run tmt on RHEL-8. (sidenote: I was able to install the wheel with all extras on el8 with python3.11 from Appstream repo)

Good news, the python3-hatchling (and hatch, hatch-vcs) have been pushed to epel9-stable and are on the same, latest version as Fedora.
I've been cleaning up the commits, and noticed I missed the tmt uses it's version. Since it's dynamic, I've re-implemented it with https://github.com/teemtee/tmt/pull/2209/commits/de2d066e8277eef3fdfe6c10ba52beb97ee86736#diff-885937bd1cee6b753c9dddce21d1cbd1a0cd4798fc7d0c9a49cab2d2470794e6.
Unfortunately, the epel9 rpm build failed because of that (works otherwise) - https://download.copr.fedorainfracloud.org/results/packit/teemtee-tmt-2209/epel-9-x86_64/06318699-tmt/builder-live.log.gz
Any ideas? Maybe it doesn't like that _version.py is in .gitignore?

setuptools_scm in rhel9 is quite old (6.0.1) and it generates just version and version_tuple, no dunder variants. The dunder options were added in 7.0 https://github.com/pypa/setuptools_scm/commit/b45e19f9f275a31873fd5e07faabef16fd0bbec0#diff-bdefa0298003efada7c465428643cc6d9c129168afb3eb5c551b40fcc77feac1L39

On fedora-39 and rawhide tests seem to be failing with the following error:
ModuleNotFoundError: No module named 'pkg_resources'

On fedora-39 and rawhide tests seem to be failing with the following error:
ModuleNotFoundError: No module named 'pkg_resources'

Other PRs don't? I thought it's deprecated in 3.12.
See https://setuptools.pypa.io/en/latest/pkg_resources.html
Would be solved by merging https://github.com/teemtee/tmt/pull/2261

Other PRs don't? I thought it's deprecated in 3.12. See https://setuptools.pypa.io/en/latest/pkg_resources.html

Hmmm, other PRs seems to be fine.

Would be solved by merging #2261

Nice. Let's get that one merged soon!

I've been unable to keep up. Will disable notifications here and if you need my help, please mention me.

Well, LGTM! I stayed away from the subpackage discussions, as I don't understand it well enough to even have an opinion :) But the rest looks good to me.

2023-09-20 22:06:45.315 commands.py       DEBUG  Command: bash -c echo dist/tmt-$(hatch version).tar.gz
2023-09-20 22:06:45.481 logging.py        INFO   dist/tmt-1.27.1.dev48+gb67a6b90.d20230920.tar.gz
2023-09-20 22:06:45.482 utils.py          ERROR  Preparation of the repository for creation of an SRPM failed: The create-archive action did not output a path to the generated archive. Please make sure that you have valid path in the single line of the output.

Not sure what's wrong here in packit world. Works for me locally by running packit srpm.

Not sure what's wrong here in packit world. Works for me locally by running packit srpm.

In the log I see two tarball names:
2023-09-20 22:06:42.967 commands.py       DEBUG  Command: hatch build -t sdist
...
2023-09-20 22:06:45.253 logging.py        INFO   dist/tmt-1.27.1.dev48+gb67a6b90.tar.gz
2023-09-20 22:06:45.315 commands.py       DEBUG  Command: bash -c echo dist/tmt-$(hatch version).tar.gz
2023-09-20 22:06:45.481 logging.py        INFO   dist/tmt-1.27.1.dev48+gb67a6b90.d20230920.tar.gz

Could it be that hatch build -t sdist produces the shorter version and we announce a different name which packit cannot find?

Could it be that hatch build -t sdist produces the shorter version and we announce a different name which packit cannot find?

Thanks. I think since we removed tmt/_version.py from .gitignore it will now see it changed after running hatch build.

Yep, nice work, it works so far!
One note though: after creating the environment (hatch -v env create dev) and entering it with shell (hatch -e dev shell), there seem to be changes made to sources:
diff --git a/tmt/_version.py b/tmt/_version.py
index 22c74322..185da99b 100644
--- a/tmt/_version.py
+++ b/tmt/_version.py
@@ -1,3 +1,8 @@
 # file generated by setuptools_scm
 # don't change, don't track in version control
-__version__ = version = 'running from source'
+TYPE_CHECKING = False
+if TYPE_CHECKING:
+    from typing import Tuple
+
+__version__ = version = '1.28.0.dev24+g1cc4b3b5'  # type: str
+__version_tuple__ = version_tuple = (1, 28, 0, 'dev24', 'g1cc4b3b5')  # type: Tuple[int | str, ...]

How shall I treat these changes?

One note though: after creating the environment (hatch -v env create dev) and entering it with shell (hatch -e dev shell), there seem to be changes made to sources:

@happz Versioning is a pain-point and the plan is to improve it in separate PR. To sum-up:
Normally, the _version.py would not be tracked by git, but if it is missing, it causes issues in 'static' tools, like mypy errors as tmt.version is missing. (there is a workaround for EPEL9 setuptools_scm version)
I believe we can just get rid of it and take advantage of importlib.metadata to get the package version. Will try to work on this asap.
btw, you should not need to create the env manually to enter shell, running hatch -e dev shell should create it if it doesn't exist, as it does with the hatch run commands.

after creating the environment (hatch -v env create dev) and entering it with shell (hatch -e dev shell), there seem to be changes made to sources

@happz @psss Should be fixed here https://github.com/teemtee/tmt/pull/2349/

One note though: after creating the environment (hatch -v env create dev) and entering it with shell (hatch -e dev shell), there seem to be changes made to sources:

@happz Versioning is a pain-point and the plan is to improve it in separate PR. To sum-up: Normally, the _version.py would not be tracked by git, but if it is missing, it causes issues in 'static' tools, like mypy errors as tmt.version is missing. (there is a workaround for EPEL9 setuptools_scm version) I believe we can just get rid of it and take advantage of importlib.metadata to get the package version. Will try to work on this asap.

Got it, thanks.

btw, you should not need to create the env manually to enter shell, running hatch -e dev shell should create it if it doesn't exist, as it does with the hatch run commands.

I just followed the documentation ;)


Create a mock up for the app

Here's a rough design. Also linked it on the wiki page: https://github.com/duluca/local-weather-app/wiki


feat: dns caching

Add a simple TTL cache for the DNS Resolver. Seperated from https://github.com/xvzc/SpoofDPI/pull/129. Re-do from #132
The idea is that since SpoofDPI currently have to perform DNS lookup on every request it make, it would get slow if a domain is requested multiple times over multiple connections (easiest example being something like a social timeline where each image is a new connection). Adding a cache here allows some of them to be kept for later requests which reduces latency.
Note that this cache implementation is NOT optimal. If there is a flood of uncached requests, some may miss the cache even when they have been written by other routines. The issue is that I've not found a way to fix the issue without effectively render the resolver single threaded :(
Also after merge you may want to set a different default TTL (like 300s). 60s might be a bit on the aggressive side for DNS caching

@TeaDove sorry for the (suuuuuuuuuuper) late response. I've take that into account and rebase the code. Please check if the implementation is acceptable

Can it lead to issues when client switches from IPv4-only connection to IPv6-only or vice versa? I assume that in such circumstances SpoofDPI will return an address from the cache, which will be unreachable from the client.

In theory, it is an issue, and we could account for that by also caching the queried type, but like, this shouldn’t happen unless you are hopping network to network in a very short amount of time.
Still, something to consider

@ohaiibuzzle It seems that caching by qType makes no sense. In any case, if the name is resolved, then we can dial a connection with ipv4 or ipv6 address

From what I can tell the matter here is a novel situation where if the cache is on v4, then somehow during cache expiry you jump from a v4-only network to v6-only (or back), it will serve a v4 address to a v6-only network (or vice versa) and fail

@LiquidTheDangerous We could but a daemon routine still have to exist to prevent a situation where a cache item that is rarely accessed is permanently stored (because it never gets accessed again to be cleared)

@ohaiibuzzle You can look at this branch, tell please how suitable it is for implementing a cache. Create a new handler and insert it into the chain


Cluster-scoped Rollouts installs

At present, the operator only supports namespace-scoped installs via the --namespaced parameter, which is currently hardcoded to be enabled by default.
Work required

Controller should default to cluster-scoped install by default

Add an optional namespaceScoped bool field to the RolloutsManager CR

if true, the current behaviour remains that the Rollouts controller will only watch the particular Namespace
if false, the RolloutsManager will watch the whole cluster

The cluster-scoped install should ensure a ClusterRole/ClusterRoleBinding exist that allow the rollouts manager to watch the whole cluster

For example, from upstream:
https://github.com/argoproj/argo-rollouts/blob/c688dd89a7f883c8c004b4024b390104b5be5770/manifests/install.yaml#L15566
https://github.com/argoproj/argo-rollouts/blob/c688dd89a7f883c8c004b4024b390104b5be5770/manifests/install.yaml#L15790
The existing Role/RoleBinding that are currently created in the Namespace does not need to be created in this case

Likewise, the cluster-scoped install should NOT run with the --namespaced parameter

In the case where there exist multiple RolloutsManager CRs on the cluster,  we should refuse to reconcile any namespace-scoped RolloutsManager CRs. The .status field should indicate why these are not being reconciled.

Unit/E2E tests (using Ginkgo) to verify each of the above

Link to Red Hat Issue Tracker: https://issues.redhat.com/browse/GITOPS-3847

Following up from an internal discussion around how to handle the mix of namespace-scoped and cluster-scoped Rollouts controllers, here's a brainstorm of how it all fits together.
Supported Scenarios
When installing Argo Rollouts controller on a cluster, there are 3 possible scenarios that could exist:
A) Cluster-scoped: 1 rollouts controller is watching for Rollouts CRs at cluster scope
B) Namespace-scoped:  1 or more Rollouts controllers are watching for Rollouts CRs at namespace scope (possible there are multiple controllers on the cluster, each watching a single namespace)
C) Hybrid: multiple Rollouts controllers on the cluster, with at most one being cluster-scoped, and the rest being namespaced-scoped. Cluster-scoped install would ignore Rollouts if there was a namespace-scoped installed.

BUT, this is just a theoretical scenario, it is not supported by Rollouts controller, AFAICT
Likewise I'm not sure if this is actually useful for any actual use case.

Thus, only the following two scenarios are supported by Argo Rollouts controller:
A) 1 cluster-scoped Rollouts controller
XOR
B) 1 or more namespace-scoped Rollouts controllers
How to ensure in argo-rollouts-manager that the cluster is always in a supported state
When reconciling RolloutsManager CRs, the Rollouts Operator can examine the current list of all RolloutManagers on the cluster, and use that to ensure that the cluster is in a valid state:

When reconciling a RolloutManager CR in Reconcile, list all existing RolloutManager CRs on the cluster. (You can do this with a k8sClient.List(...) call, just making sure NOT to specify a namespace as part of the ListOptions. The RolloutManager controller should always already have permission to do this).
If there exists > 1 cluster-scoped RolloutManagers, set an error on the RolloutManager CR and exit.
If there exist 1 cluster-scoped Rollouts Manager, and 1 or more namespace-scoped Rollouts manager, likewise, set an error and exit.

Reconcile() should ONLY sets the .status field of the particular RolloutManager CR that it is reconciling. Don't worry about setting the status field of other RolloutManager CRs that might exist on the cluster. (These will eventually be reconciled on K8s controller resync, which occurs every X hours. So they will eventually have an error set)
Preventing denial of service (DOS)
Can we prevent a DOS, where a malicious user creates a RolloutManager in their own Namespace, which moves Rollouts controller into an unsupported use case?
An interesting question, and after some thought, while this is theoretically possible, I think this is already reasonably mitigated:

For example, if a user does create a namespace-scoped RolloutManager CR in their Namespace, the cluster-scoped RolloutManager CR, which was already installed, will continue to remain installed and running.

Specifically, the Deployment, ConfigMap, etc, of the cluster-scoped Rollout install will continue to run.
The behaviour is: Even though we put the RolloutsManager CR in an error state, we are not deleting any of the existing K8s resources (Deployments, etc), nor are we scaling the replicas down to 0.

Users are not automatically given permission to create RolloutManager CRs by default: it is reasonable to expect cluster admins to carefully hand out this permission via RBAC.

In the future, we could possibly something even fancier, perhaps with webhooks, or perhaps by adding support to upstream rollouts, but I think the above case is strong enough that it's fair to wait for a customer/user request before we work on this.


Multiple groups for single tab

I'm writing some documentation where we support distributions of Linux. There are some elements of the document that are not distribution specific, but where we describe generic Linux support.
When clicking on these tabs, it would be great if Arch Linux and Ubuntu/Debian were secretly tied to Linux somehow, without effecting the displayed group name. This way, if someone clicks Ubuntu/Debian or Arch Linux, it would be grouped to generic Linux. I do understand how conflicts could arise, but I'm just here to suggest the idea.
Of course Arch Linux and Ubuntu/Debian are both Linux, and I want it to be possible to link them to the generic Linux docs, since they are related, but as you can see they are not grouped in the gif below, and it would not be possible for me to do so currently I believe.
Thanks a lot for this great project :)

A simple way to solve this would be to have it so that the displayed name is not the same as the group name. This way, I could solve this particular case by naming it "Ubuntu/Debian" meanwhile grouping it as "Linux".

It would certainly be possibly to allow an alternative group name, though what would be the expected action if Linux was clicked in the second set of tabs here? As I think the current JS would try to "activate" both tabs in the first set with a matching group name

Oddly, I've found that this plugin implements everything exactly as I have described. https://sphinxcontrib-platformpicker.readthedocs.io/en/stable/usage.html


Pushover server doesn't appear to work

Dashboard in pushover sends to the phone, but doing it via the docs on here gives no pushes.
https://github.com/jreese/znc-push/blob/master/doc/pushover.md
<*push> service: pushover
<*push> service_host: api.pushover.net
<*push> service_url: /1/messages.json
<*push> service_auth:
<*push> use_port: 443
<*push> use_ssl: 1
<*push> use_post: 1
<*push> NOT using libcurl
<*push> Building notification to api.pushover.net/1/messages.json...
<*push> User-Agent: ZNC Push/dev
<*push> Query string: device=clt-l29&message=test&priority=0&title=New+Message&token=secretfrompushover&user=userkeyfrompushover
<*push> Request sending
<*push> Ok
<*push> Disconnected.

I know Pushover works because my push instance sends dozens of notifications to me every day via that service.
My instance doesn't have a target set, though. If you do, try removing that. The docs or code for that specific setting could be wrong, I guess.

Had the same issue, unsetting the target fixed it.


how to add class to node?

how to add class to node?

There is a li_attr and a_attr to every node.


[Bug]: json_clean_up repair json faulty ，but increase index time and global search time 70-80%

Although json_clean_up repair json faulty responses，it increases index time and global search time 70-80%
here are some time comparation :
v0.2.0 index time 35min , v0.2.1 62min
v0.2.0 global search time 45s , v0.2.1 75s
I want to back 0.2.0,  will  some json faulty responses will decrease search qulity ?
I can't see big difference of global search result between v0.2.0 and v0.2.1

Addressing this issue on #834

I'll resolve this as we added some changes in version 0.2.1 to address this. But, please reopen if need, I'll be on the lookout!
Btw, highly appreciate this type of dive deep and insights, really helps us improving the library together!


Adding basic auth to the WriteHttp plugin and minor functionality extentions

My cloud monitoring platform requires key/secret authentication, so I added it to the WriteHttp plugin. There are a couple of minor additional updates to suppress a spurious error in TypeDB loading and additional tracing in WriteHttp for pre-POST and server reply detail.

Nice! Just what we need!

@yogeswaran Please see the changes in the last updates per your suggestions.  Thx!

Documentation in wiki updated

:+1:

@FerventGeek - thanks for the PR!

:boom::sparkles::zap::cake:

Fantastic! @yogeswaran: any estimate when there will be a new msi release?

I am planning to have a new release on Wed.


refactor implementation to avoid thread safety issues for user inputs

resolves formigarafa/zxcvbn-rb#8
I opted for the simple approach of passing the dictionary around as suggested in the original issue.

Really nice and spotless implementation. ✨
Thank you. ❤


Generate files with the right UTI

Context 🕵♀
From Apple:

Uniform type identifiers (UTIs) provide a unified way to identify data handled within the system, such as documents, pasteboard data, and bundles. This chapter describes the concepts behind UTIs and shows how to specify them in your application bundles.

Reference
What 🌱
Make sure workspaces and projects are written with the right UTI. The UTI of a file can be obtained running mdls path/to/file. Here are the UTIs of the Xcode project files:

Workspace: com.apple.dt.document.workspace
Project: com.apple.xcode.project.

Proposal 🎉
Change the writing logic to set the UTI attribute on the written files.

 Generate files with the right UTI

@y-matsuwitter funded this issue with $40. Visit this issue on Issuehunt


[FEATURE] Output PDM audio on GPIO pin (DAC)

Is your feature request related to a problem? Please describe.
We need to be able to output audio from ESP to host radio. That would be a building block for future scrambling and digital modes.
Describe the solution you'd like
For initial tests:

Load pre-recorded PDM audio sample.
Output the PDM audio to GPIO pin.
Make sure the audio can be heard by connecting headphones to the GPIO pin.

Additional context
Here is a website that describes in detail how this can be done:
https://hackaday.com/2024/01/06/no-dac-try-pdm/

done


Gltf-Pipeline in Browser

Hello,
I try to include gltf-pipeline in a react app. So I browserified it: https://wzrd.in/standalone/gltf-pipeline@latest
Unfortunately it throws a lot of errors:
Line 1:1:         Expected an assignment or function call and instead saw an expression  no-unused-expressions
  Line 1:124:       'define' is not defined                                                no-undef
  Line 1:135:       'define' is not defined                                                no-undef
  Line 1:242:       Unexpected use of 'self'                                               no-restricted-globals
  Line 1:247:       Unexpected use of 'self'

Is it anyhow possible to do that?
Best

I believe you can't run an dracoCompression from browser client. I suggest you to use nextjs api routes for compression and send it back via response to the client.


Minecraft 1.21 Forge getsockopt

Describe the problem
When running a minecraft curseforge server on 1.21 and trying to join, I get the following error:
Connection refused: getsockopt;
Container definition
docker run -d -it -p 25565:25565 -e EULA=TRUE -e TYPE=FORGE -e VERSION=1.21 itzg/minecraft-server

Container logs
[init] Running as uid=1000 gid=1000 with /data as 'drwxr-x--- 2 1000 1000 4096 Jun 15 19:17 /data'
[init] Resolving type given FORGE
[mc-image-helper] 22:04:52.603 INFO  : Downloading Forge installer 51.0.17 for Minecraft 1.21
[mc-image-helper] 22:04:53.070 INFO  : Running Forge 51.0.17 installer for Minecraft 1.21. This might take a while...
[init] Creating server properties in /data/server.properties
[init] Disabling whitelist functionality
[mc-image-helper] 22:05:25.471 INFO  : Created/updated 4 properties in /data/server.properties
[init] Setting initial memory to 1G and max to 1G
[init] Using Forge supplied run.sh script...
WARN StatusConsoleListener The use of package scanning to locate plugins is deprecated and will be removed in a future release
WARN StatusConsoleListener The use of package scanning to locate plugins is deprecated and will be removed in a future release
WARN StatusConsoleListener The use of package scanning to locate plugins is deprecated and will be removed in a future release
WARN StatusConsoleListener The use of package scanning to locate plugins is deprecated and will be removed in a future release
[22:05:28] [main/INFO] [cp.mo.mo.Launcher/MODLAUNCHER]: ModLauncher running: args [--launchTarget, forge_server]
[22:05:28] [main/INFO] [cp.mo.mo.Launcher/MODLAUNCHER]: JVM identified as Eclipse Adoptium OpenJDK 64-Bit Server VM 21.0.3+9-LTS
[22:05:28] [main/INFO] [cp.mo.mo.Launcher/MODLAUNCHER]: ModLauncher 10.2.1 starting: java version 21.0.3 by Eclipse Adoptium; OS Linux arch aarch64 version 6.6.31-linuxkit
[22:05:28] [main/WARN] [ne.mi.fm.lo.FMLConfig/CORE]: Configuration file /data/config/fml.toml is not correct. Correcting
[22:05:28] [main/INFO] [ne.mi.fm.lo.FMLConfig/CORE]: Incorrect key [earlyWindowSkipGLVersions] was corrected from null to []
[22:05:28] [main/INFO] [ne.mi.fm.lo.FMLConfig/CORE]: Incorrect key [earlyWindowLogHelpMessage] was corrected from null to true
[22:05:28] [main/INFO] [ne.mi.fm.lo.FMLConfig/CORE]: Incorrect key [earlyWindowSquir] was corrected from null to false
[22:05:28] [main/INFO] [ne.mi.fm.lo.FMLConfig/CORE]: Incorrect key [earlyWindowShowCPU] was corrected from null to false
[22:05:28] [main/INFO] [ne.mi.fm.lo.ImmediateWindowHandler/]: ImmediateWindowProvider not loading because launch target is forge_server
[22:05:28] [main/INFO] [mixin/]: SpongePowered MIXIN Subsystem Version=0.8.5 Source=jar:file:///data/libraries/org/spongepowered/mixin/0.8.5/mixin-0.8.5.jar!/ Service=ModLauncher Env=SERVER
[22:05:28] [main/INFO] [ne.mi.fm.lo.mo.JarInJarDependencyLocator/]: No dependencies to load found. Skipping!
[22:05:29] [main/INFO] [cp.mo.mo.LaunchServiceHandler/MODLAUNCHER]: Launching target 'forge_server' with arguments []
[22:05:29] [main/WARN] [os.ut.FileUtil/]: Configuration conflict: there is more than one oshi.properties file on the classpath: [jar:file:///data/libraries/com/github/oshi/oshi-core/6.4.10/oshi-core-6.4.10.jar!/oshi.properties, jar:file:/data/libraries/com/github/oshi/oshi-core/6.4.10/oshi-core-6.4.10.jar!/oshi.properties, jar:file:///data/libraries/com/github/oshi/oshi-core/6.4.10/oshi-core-6.4.10.jar!/oshi.properties, jar:file:/data/libraries/com/github/oshi/oshi-core/6.4.10/oshi-core-6.4.10.jar!/oshi.properties]
[22:05:29] [main/WARN] [os.ut.FileUtil/]: Configuration conflict: there is more than one oshi.architecture.properties file on the classpath: [jar:file:///data/libraries/com/github/oshi/oshi-core/6.4.10/oshi-core-6.4.10.jar!/oshi.architecture.properties, jar:file:/data/libraries/com/github/oshi/oshi-core/6.4.10/oshi-core-6.4.10.jar!/oshi.architecture.properties, jar:file:///data/libraries/com/github/oshi/oshi-core/6.4.10/oshi-core-6.4.10.jar!/oshi.architecture.properties, jar:file:/data/libraries/com/github/oshi/oshi-core/6.4.10/oshi-core-6.4.10.jar!/oshi.architecture.properties]
[22:05:31] [modloading-worker-0/INFO] [ne.mi.co.ForgeMod/FORGEMOD]: Forge mod loading, version 51.0.17, for MC 1.21 with MCP 20240613.102039
[22:05:31] [modloading-worker-0/INFO] [ne.mi.co.MinecraftForge/FORGE]: MinecraftForge v51.0.17 Initialized
[22:05:31] [modloading-worker-0/INFO] [ne.mi.co.ForgeMod/FORGEMOD]: Opening jdk.naming.dns/com.sun.jndi.dns to java.naming
[22:05:31] [Forge Version Check/INFO] [ne.mi.fm.VersionChecker/]: [forge] Starting version check at https://files.minecraftforge.net/net/minecraftforge/forge/promotions_slim.json
[22:05:31] [Forge Version Check/INFO] [ne.mi.fm.VersionChecker/]: [forge] Found status: BETA Current: 51.0.17 Target: 51.0.17
[22:05:32] [main/INFO] [mojang/YggdrasilAuthenticationService]: Environment: Environment[sessionHost=https://sessionserver.mojang.com, servicesHost=https://api.minecraftservices.com, name=PROD]
[22:05:32] [main/INFO] [minecraft/Main]: No existing world data, creating new world
[22:05:32] [main/INFO] [minecraft/RecipeManager]: Loaded 1290 recipes
[22:05:32] [main/INFO] [minecraft/AdvancementTree]: Loaded 1399 advancements
[22:05:32] [Server thread/INFO] [minecraft/DedicatedServer]: Starting minecraft server version 1.21
[22:05:32] [Server thread/INFO] [minecraft/DedicatedServer]: Loading properties
[22:05:32] [Server thread/INFO] [minecraft/DedicatedServer]: Default game type: SURVIVAL
[22:05:32] [Server thread/INFO] [minecraft/MinecraftServer]: Generating keypair
[22:05:32] [Server thread/INFO] [minecraft/DedicatedServer]: Starting Minecraft server on *:25565
[22:05:33] [Server thread/INFO] [minecraft/ServerConnectionListener]: Using default channel type
[22:05:33] [Server thread/WARN] [ne.mi.co.ForgeConfigSpec/CORE]: Configuration file ./world/serverconfig/forge-server.toml is not correct. Correcting
[22:05:33] [Server thread/WARN] [ne.mi.co.ForgeConfigSpec/CORE]: Incorrect key server was corrected from null to its default, SynchronizedConfig{DataHolder:{}}.
[22:05:33] [Server thread/WARN] [ne.mi.co.ForgeConfigSpec/CORE]: Incorrect key server.removeErroringBlockEntities was corrected from null to its default, false.
[22:05:33] [Server thread/WARN] [ne.mi.co.ForgeConfigSpec/CORE]: Incorrect key server.removeErroringEntities was corrected from null to its default, false.
[22:05:33] [Server thread/WARN] [ne.mi.co.ForgeConfigSpec/CORE]: Incorrect key server.fullBoundingBoxLadders was corrected from null to its default, false.
[22:05:33] [Server thread/WARN] [ne.mi.co.ForgeConfigSpec/CORE]: Incorrect key server.permissionHandler was corrected from null to its default, forge:default_handler.
[22:05:33] [Server thread/WARN] [ne.mi.co.ForgeConfigSpec/CORE]: Incorrect key server.advertiseDedicatedServerToLan was corrected from null to its default, true.
[22:05:33] [Server thread/INFO] [minecraft/DedicatedServer]: Preparing level "world"
[22:05:35] [Server thread/INFO] [minecraft/MinecraftServer]: Preparing start region for dimension minecraft:overworld
[22:05:35] [Worker-Main-1/INFO] [minecraft/LoggerChunkProgressListener]: Preparing spawn area: 2%
[22:05:36] [Worker-Main-3/INFO] [minecraft/LoggerChunkProgressListener]: Preparing spawn area: 2%
[22:05:36] [Worker-Main-2/INFO] [minecraft/LoggerChunkProgressListener]: Preparing spawn area: 18%
[22:05:37] [Netty Server IO #1/INFO] [ne.mi.se.ServerLifecycleHooks/SERVERHOOKS]: [/[::1]:46374] Disconnecting VANILLA connection attempt: Server is still starting! Please wait before reconnecting.
[22:05:37] [Worker-Main-4/INFO] [minecraft/LoggerChunkProgressListener]: Preparing spawn area: 51%
[22:05:37] [Server thread/INFO] [minecraft/LoggerChunkProgressListener]: Time elapsed: 1842 ms
[22:05:37] [Server thread/INFO] [minecraft/DedicatedServer]: Done (4.368s)! For help, type "help"
[22:05:37] [Server thread/INFO] [minecraft/DedicatedServer]: Starting remote control listener
[22:05:37] [Server thread/INFO] [minecraft/GenericThread]: Thread RCON Listener started
[22:05:37] [Server thread/INFO] [minecraft/RconThread]: RCON running on <IP_ADDRESS>:25575
[22:05:37] [LanServerPinger #1/WARN] [minecraft/LanServerPinger]: LanServerPinger: Network is unreachable
[22:05:37] [Server thread/INFO] [ne.mi.se.pe.PermissionAPI/]: Successfully initialized permission handler forge:default_handler

You have configured the container correctly and logs indicate it is ready for connections
[22:05:32] [Server thread/INFO] [minecraft/DedicatedServer]: Starting Minecraft server on *:25565

One of the mods may be causing problems or its because 1.21 is very new. Either way it's not something can be fixed by this image.

The issue is this is an empty server with no mods, so maybe it's just an issue with 1.21 forge itself?  For help, type "help"
06/29/2024
02:14:26 PM
[21:14:26] [Server thread/INFO]: Starting remote control listener
06/29/2024
02:14:26 PM
[21:14:26] [Server thread/INFO]: Thread RCON Listener started
06/29/2024
02:14:26 PM
[21:14:26] [Server thread/INFO]: RCON running on <IP_ADDRESS>:25575

Please report these issues with Forge or the modpack author. I have no ability to "fix" these types of issues.

I got a similar problem, but with a vanilla server... I use a fabric install with some client mods like sodium, the Server Im trying to join is vanilla with some plugins. I do not habe access to the server side of things, but since it restarted rejoining is impossible for me, although the others can join.
I already made all the troubleshooting steps which are viable for a similar problem in 1.20.6 (same error message) which was n exception in my firewall for Jawaw.exe
Here is the extract relevant from the log: (complete version below)
[12:59:19] [ForkJoinPool.commonPool-worker-1/INFO]:
Verifying Minecraft session...
[12:59:20] [ForkJoinPool.commonPool-worker-1/INFO]:
The Minecraft session is valid
[12:59:21] [Render thread/INFO]:
Adding auth button to the multiplayer screen
[12:59:22] [Render thread/INFO]:
Connecting to mc.azgeda.de, 25576
[12:59:43] [Server Connector #1/ERROR]:
Couldn't connect to server
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection timed out: getsockopt: mc.azgeda.de/<IP_ADDRESS>:25576
Caused by: java.net.ConnectException: Connection timed out: getsockopt
at java.base/sun.nio.ch.Net.pollConnect(Native Method) ~[?:?]
at java.base/sun.nio.ch.Net.pollConnectNow(Unknown Source) ~[?:?]
at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source) ~[?:?]
at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:337) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:334) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.97.Final.jar:?]
at java.base/java.lang.Thread.run(Unknown Source) ~[?:?]
The full log:

null[12:58:14] [main/INFO]: Loading Minecraft 1.21 with Fabric Loader 0.15.11

[12:58:14] [ForkJoinPool-1-worker-3/WARN]: Mod dev_isxander_libsdl4j uses the version 3.6896c4c-38 which isn't compatible with Loader's extended semantic version format (Could not parse version number component '6896c4c'!), SemVer is recommended for reliably evaluating dependencies and prioritizing newer version
[12:58:14] [main/INFO]: Dependencies overridden for minecraft, dynamic_fps, lambdynlights, fabricloader, polytone
[12:58:15] [main/WARN]: Warnings were found!

'Minecraft' (minecraft) 1.21 recommends any version after 6.0.0-alpha.5 of Fabulously Optimized, which is missing!

 (YOSBR)
[12:58:15] [main/INFO]: SpongePowered MIXIN Subsystem Version=0.8.5 Source=file:/C:/Users/{COMPUTER_USERNAME}/AppData/Roaming/com.modrinth.theseus/meta/libraries/net/fabricmc/sponge-mixin/0.13.3+mixin.0.8.5/sponge-mixin-0.13.3+mixin.0.8.5.jar Service=Knot/Fabric Env=CLIENT
[12:58:15] [main/INFO]: Compatibility level set to JAVA_16
[12:58:15] [main/INFO]: Compatibility level set to JAVA_21
[12:58:16] [main/INFO]: Preloading Debugify
[12:58:17] [main/INFO]: Loaded configuration file for Lithium: 138 options available, 1 override(s) found
[12:58:17] [main/INFO]: Loaded configuration file for ModernFix 5.18.3+mc1.21: 55 options available, 0 override(s) found
[12:58:17] [main/INFO]: Applying Nashorn fix
[12:58:17] [main/INFO]: Loaded configuration file for Sodium: 42 options available, 3 override(s) found
[12:58:17] [main/INFO]: Loaded configuration file for Sodium Extra: 35 options available, 0 override(s) found
[12:58:18] [main/WARN]: Force disabled MC-122477 because it only applies to OS: LINUX
[12:58:18] [main/WARN]: Force disabled MC-22882 because it only applies to OS: MAC
[12:58:18] [main/WARN]: Force disabled MC-59810 because it only applies to OS: MAC
[12:58:18] [main/WARN]: Error loading class: net/raphimc/immediatelyfast/feature/core/ImmediateAdapter (java.lang.ClassNotFoundException: net/raphimc/immediatelyfast/feature/core/ImmediateAdapter)
[12:58:18] [main/WARN]: Error loading class: dev/tr7zw/skinlayers/render/CustomizableModelPart (java.lang.ClassNotFoundException: dev/tr7zw/skinlayers/render/CustomizableModelPart)
[12:58:18] [main/WARN]: Error loading class: me/jellysquid/mods/sodium/client/render/vertex/buffer/SodiumBufferBuilder (java.lang.ClassNotFoundException: me/jellysquid/mods/sodium/client/render/vertex/buffer/SodiumBufferBuilder)
[12:58:18] [main/WARN]: Force-disabling mixin 'alloc.blockstate.StateMixin' as rule 'mixin.alloc.blockstate' (added by mods [ferritecore]) disables it and children
[12:58:19] [main/WARN]: Error loading class: xyz/nucleoid/server/translations/impl/language/SystemDelegatedLanguage (java.lang.ClassNotFoundException: xyz/nucleoid/server/translations/impl/language/SystemDelegatedLanguage)
[12:58:19] [main/WARN]: Force-disabling mixin 'features.render.entity.CuboidMixin' as rule 'mixin.features.render.entity' (added by mods [iris]) disables it and children
[12:58:19] [main/WARN]: Force-disabling mixin 'features.render.entity.ModelPartMixin' as rule 'mixin.features.render.entity' (added by mods [iris]) disables it and children
[12:58:19] [main/WARN]: Force-disabling mixin 'features.render.entity.cull.EntityRendererMixin' as rule 'mixin.features.render.entity' (added by mods [iris]) disables it and children
[12:58:19] [main/WARN]: Force-disabling mixin 'features.render.entity.shadows.EntityRenderDispatcherMixin' as rule 'mixin.features.render.entity' (added by mods [iris]) disables it and children
[12:58:19] [main/WARN]: Force-disabling mixin 'features.render.gui.font.GlyphRendererMixin' as rule 'mixin.features.render.gui.font' (added by mods [iris]) disables it and children
[12:58:19] [main/WARN]: Force-disabling mixin 'features.render.world.sky.BackgroundRendererMixin' as rule 'mixin.features.render.world.sky' (added by mods [iris]) disables it and children
[12:58:19] [main/WARN]: Force-disabling mixin 'features.render.world.sky.ClientWorldMixin' as rule 'mixin.features.render.world.sky' (added by mods [iris]) disables it and children
[12:58:19] [main/WARN]: Force-disabling mixin 'features.render.world.sky.WorldRendererMixin' as rule 'mixin.features.render.world.sky' (added by mods [iris]) disables it and children
[12:58:19] [main/WARN]: Error loading class: org/jetbrains/annotations/ApiStatus$Internal (java.lang.ClassNotFoundException: org/jetbrains/annotations/ApiStatus$Internal)
[12:58:19] [main/WARN]: Error loading class: org/jetbrains/annotations/ApiStatus$Internal (java.lang.ClassNotFoundException: org/jetbrains/annotations/ApiStatus$Internal)
[12:58:19] [main/INFO]: Searching for graphics cards...
[12:58:20] [main/INFO]: Found graphics adapter: AdapterInfo{vendor=NVIDIA, description='NVIDIA GeForce GTX 970', adapterType=0x0000030B, openglIcdFilePath='C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_5714f0dca6485379\nvoglv64.dll', openglIcdVersion=<IP_ADDRESS>12}
[12:58:20] [main/WARN]: Sodium has applied one or more workarounds to prevent crashes or other issues on your system: [NVIDIA_THREADED_OPTIMIZATIONS]
[12:58:20] [main/WARN]: This is not necessarily an issue, but it may result in certain features or optimizations being disabled. You can sometimes fix these issues by upgrading your graphics driver.
[12:58:21] [main/INFO]: Initializing MixinExtras via com.llamalad7.mixinextras.service.MixinExtrasServiceImpl(version=0.3.5).
[12:58:24] [Datafixer Bootstrap/INFO]: 226 Datafixer optimizations took 846 milliseconds
[12:58:26] [main/INFO]: Injecting BlockStateBase cache population hook into lithium$getPathNodeType from me.jellysquid.mods.lithium.mixin.ai.pathing.AbstractBlockStateMixin
[12:58:26] [main/INFO]: Injecting BlockStateBase cache population hook into lithium$getAllFlags from me.jellysquid.mods.lithium.mixin.util.block_tracking.AbstractBlockStateMixin
[12:58:26] [main/INFO]: Injecting BlockStateBase cache population hook into lithium$getNeighborPathNodeType from me.jellysquid.mods.lithium.mixin.ai.pathing.AbstractBlockStateMixin
[12:58:28] [main/WARN]: Static binding violation: PRIVATE @Overwrite method method_21740 in modernfix-common.mixins.json:perf.remove_biome_temperature_cache.BiomeMixin from mod modernfix cannot reduce visibiliy of PUBLIC target method, visibility will be upgraded.
[12:58:28] [main/WARN]: Method overwrite conflict for method_21740 in modernfix-common.mixins.json:perf.remove_biome_temperature_cache.BiomeMixin from mod modernfix, previously written by me.jellysquid.mods.lithium.mixin.world.temperature_cache.BiomeMixin. Skipping method.
[12:58:33] [main/INFO]: Vanilla bootstrap took 9101 milliseconds
[12:58:34] [Render thread/INFO]: Environment: Environment[sessionHost=https://sessionserver.mojang.com, servicesHost=https://api.minecraftservices.com, name=PROD]
[12:58:34] [Render thread/INFO]: Setting user: {MINECRAFT_USERNAME}
[12:58:35] [Render thread/INFO]: Loading Collective version 7.64.
[12:58:35] [Render thread/INFO]: Enabled 10 bug fixes: [MC-577, MC-22882, MC-59810, MC-89146, MC-90683, MC-112730, MC-122477, MC-199467, MC-237493, MC-263865]
[12:58:35] [Render thread/INFO]: Successfully Debugify'd your game!
[12:58:36] [Render thread/INFO]: assume less - mald more
[12:58:38] [Render thread/INFO]: Trying to read config file...
[12:58:38] [Render thread/INFO]: A config file was found, loading it..
[12:58:38] [Render thread/INFO]: Successfully loaded config file.
[12:58:38] [Render thread/INFO]: Pre-initializing Controlify...
[12:58:38] [Render thread/INFO]: Initializing Distant Horizons
[12:58:38] [Render thread/INFO]: Java.awt.headless set to true. Distant Horizons can correctly display error and info dialog windows.
[12:58:38] [Render thread/INFO]: Distant Horizons, Version: 2.1.2-a
[12:58:38] [Render thread/INFO]: DH Branch: main
[12:58:38] [Render thread/INFO]: DH Commit: 095fff96ff360513ae486764ec5942f778b50300
[12:58:38] [Render thread/INFO]: DH Jar Build Source: User
[12:58:38] [Render thread/INFO]: Registering Fabric Client Events
[12:58:38] [Render thread/INFO]: Registering Fabric Server Events
[12:58:38] [Render thread/INFO]: Registered mod compatibility accessor for: [Sodium-Fabric].
[12:58:38] [Render thread/INFO]: Registered mod compatibility accessor for: [iris].
[12:58:38] [Render thread/INFO]: Distant Horizons Initialized
[12:58:38] [Render thread/INFO]: Initialising config for DistantHorizons
[12:58:39] [Render thread/INFO]: Config for DistantHorizons initialised
[12:58:39] [Render thread/INFO]: Dynamic FPS 3.4.3 active on Fabric!
[12:58:39] [Render thread/INFO]: Loading Entity Model Features, not fit for consumption in Portugal.
[12:58:40] [Render thread/INFO]: 6 new ETF Random Properties registered by entity_model_features.
[12:58:40] [Render thread/INFO]: Loading Entity Texture Features, Thanks for 10 Million plus downloads!!
[12:58:40] [Render thread/INFO]: [Indigo] Different rendering plugin detected; not applying Indigo.
[12:58:40] [Render thread/INFO]: [FastQuit] Initialized
[12:58:40] [Render thread/INFO]: Inventive Inventory initialized successfully!
[12:58:40] [Render thread/INFO]: [STDOUT]: [Mouse Tweaks] Main.initialize()
[12:58:41] [Render thread/INFO]: [STDOUT]: [Mouse Tweaks] Initialized.
[12:58:42] [Render thread/INFO]: Loading Xaero's Minimap - Stage 1/2
[12:58:42] [DH-ApplyConfigPresetTimer/INFO]: changing preset to: LOW_IMPACT
[12:58:42] [DH-ApplyConfigPresetTimer/INFO]: changing preset to: MEDIUM
[12:58:42] [DH-ApplyConfigPresetTimer/INFO]: preset active: MEDIUM
[12:58:42] [DH-ApplyConfigPresetTimer/INFO]: preset active: LOW_IMPACT
[12:58:42] [Render thread/INFO]: Loading Xaero's World Map - Stage 1/2
[12:58:44] [Render thread/INFO]: Deserializing YACLConfig from 'C:\Users{COMPUTER_USERNAME}\AppData\Roaming\com.modrinth.theseus\profiles\Fabulously Optimized\config\yacl.json5'
[12:58:44] [Render thread/INFO]: Queuing DH event binding...
[12:58:44] [Render thread/INFO]: DH Ready, binding Iris event handlers...
[12:58:44] [Render thread/INFO]: DH Iris events bound.
[12:58:45] [Render thread/WARN]: Pack distanthorizons declared support for versions [16, 90000] but declared main format is 7, defaulting to 7
[12:58:45] [Render thread/INFO]: Backend library: LWJGL version 3.3.3-snapshot
[12:58:45] [Render thread/WARN]: Applying workaround: Prevent the NVIDIA OpenGL driver from using broken optimizations (NVIDIA_THREADED_OPTIMIZATIONS)
[12:58:46] [Render thread/INFO]: Initializing ImmediatelyFast 1.2.18+1.21 on NVIDIA GeForce GTX 970/PCIe/SSE2 (NVIDIA Corporation) with OpenGL 3.2.0 NVIDIA 556.12
[12:58:46] [Render thread/INFO]: Found Iris/Oculus 1.7.1+mc1.21. Enabling compatibility.
[12:58:46] [Render thread/INFO]: Debug functionality is disabled.
[12:58:46] [Render thread/INFO]: ARB_direct_state_access detected, enabling DSA.
[12:58:46] [Render thread/INFO]: Shaders are disabled because enableShaders is set to false in iris.properties
[12:58:46] [Render thread/WARN]: Pack distanthorizons declared support for versions [16, 90000] but declared main format is 7, defaulting to 7
[12:58:47] [Render thread/INFO]: Hardware information:
[12:58:47] [Render thread/INFO]: CPU: 4x Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz
[12:58:47] [Render thread/INFO]: GPU: NVIDIA GeForce GTX 970/PCIe/SSE2 (Supports OpenGL 3.2.0 NVIDIA 556.12)
[12:58:47] [Render thread/INFO]: OS: Windows 10 (10.0)
[12:58:48] [Render thread/INFO]: Starting up renderer (fabric)
[12:58:48] [Render thread/INFO]: Renderer starting up.
[12:58:48] [Render thread/INFO]: Creating GLProxy... If this is the last message you see there must have been an OpenGL error.
[12:58:48] [Render thread/INFO]: Lod Render OpenGL version [3.2.0 NVIDIA 556.12].
[12:58:48] [Render thread/INFO]: minecraftGlCapabilities:
Your OpenGL support:
openGL version 3.2+: [true] <- REQUIRED
Vertex Attribute Buffer Binding: [true] <- optional improvement
Buffer Storage: [true] <- optional improvement

[12:58:48] [Render thread/INFO]: GPU Vendor [NVIDIA CORPORATION], Preferred upload method is [BUFFER_STORAGE].
[12:58:48] [Render thread/INFO]: GLProxy creation successful. OpenGL smiles upon you this day.
[12:58:48] [Render thread/INFO]: DH TerraFirmaCraft detection: false
[12:58:48] [Render thread/INFO]: Invalidating pack caches
[12:58:48] [Render thread/INFO]: Reloading ResourceManager: vanilla, fabric, animatica, appleskin, authme, autofish, balm-fabric, bobby, caffeineconfig, capes, cloth-config, continuity, controlify, debugify, distanthorizons, dynamic_fps, e4mc_minecraft, enhancedblockentities, entity_model_features, entity_texture_features, entityculling, fabric-api, fabric-api-base, fabric-api-lookup-api-v1, fabric-biome-api-v1, fabric-block-api-v1, fabric-block-view-api-v2, fabric-blockrenderlayer-v1, fabric-client-tags-api-v1, fabric-command-api-v1, fabric-command-api-v2, fabric-commands-v0, fabric-content-registries-v0, fabric-convention-tags-v1, fabric-convention-tags-v2, fabric-crash-report-info-v1, fabric-data-attachment-api-v1, fabric-data-generation-api-v1, fabric-dimensions-v1, fabric-entity-events-v1, fabric-events-interaction-v0, fabric-game-rule-api-v1, fabric-item-api-v1, fabric-item-group-api-v1, fabric-key-binding-api-v1, fabric-keybindings-v0, fabric-language-kotlin, fabric-lifecycle-events-v1, fabric-loot-api-v2, fabric-message-api-v1, fabric-model-loading-api-v1, fabric-networking-api-v1, fabric-object-builder-api-v1, fabric-particles-v1, fabric-recipe-api-v1, fabric-registry-sync-v0, fabric-renderer-api-v1, fabric-renderer-indigo, fabric-renderer-registries-v1, fabric-rendering-data-attachment-v1, fabric-rendering-fluids-v1, fabric-rendering-v0, fabric-rendering-v1, fabric-resource-conditions-api-v1, fabric-resource-loader-v0, fabric-screen-api-v1, fabric-screen-handler-api-v1, fabric-sound-api-v1, fabric-transfer-api-v1, fabric-transitive-access-wideners-v1, fabricloader, fabricskyboxes, fabrishot, fastquit, fishology, fishology-core, fsb-interop, immediatelyfast, indium, inventive_inventory, inventoryessentials, iris, languagereload, lithium, midnightlib, mixintrace, modernfix, modmenu, morechathistory, nochatreports, optigui, owo, paginatedadvancements, polytone, puzzle, puzzle-base, puzzle-gui, puzzle-models, puzzle-splashscreen, reeses-sodium-options, rrls, sodium, sodium-extra, xaerominimap, xaeroworldmap, xaerozoomout, yet_another_config_lib_v3, yosbr, zoomify, continuity:glass_pane_culling_fix, continuity:default, file/SodiumTranslations.zip, file/Mod Menu Helper.zip, file/Chat Reporting Helper.zip, file/Fast Better Grass.zip
[12:58:48] [Worker-ResourceReload-1/INFO]: Found unifont_all_no_pua-15.1.05.hex, loading
[12:58:49] [Render thread/INFO]: Post-Initializing Mod
[12:58:49] [Render thread/INFO]: Mod Post-Initialized
[12:58:49] [Worker-ResourceReload-1/INFO]: Found unifont_jp_patch-15.1.05.hex, loading
[12:58:49] [Render thread/INFO]: Loading Xaero's World Map - Stage 2/2
[12:58:49] [Render thread/INFO]: New world map region cache hash code: -2045510127
[12:58:49] [Render thread/INFO]: Registered player tracker system: map_synced
[12:58:49] [Render thread/INFO]: Xaero's WorldMap Mod: Xaero's minimap found!
[12:58:49] [Render thread/INFO]: Registered player tracker system: minimap_synced
[12:58:49] [Render thread/INFO]: No Optifine!
[12:58:49] [Render thread/INFO]: Xaero's World Map: No Vivecraft!
[12:58:49] [Render thread/INFO]: Xaero's World Map: Iris found!
[12:58:50] [Render thread/INFO]: Loading Xaero's Minimap - Stage 2/2
[12:58:51] [Render thread/ERROR]: suppressed exception
java.net.SocketTimeoutException: Read timed out
at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(Unknown Source) ~[?:?]
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Unknown Source) ~[?:?]
at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source) ~[?:?]
at java.base/sun.net.www.protocol.http.HttpURLConnection$10.run(Unknown Source) ~[?:?]
at java.base/sun.net.www.protocol.http.HttpURLConnection$10.run(Unknown Source) ~[?:?]
at java.base/java.security.AccessController.doPrivileged(Unknown Source) ~[?:?]
at java.base/sun.net.www.protocol.http.HttpURLConnection.getChainedException(Unknown Source) ~[?:?]
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source) ~[?:?]
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) ~[?:?]
at xaero.common.misc.Internet.checkModVersion(Internet.java:55) [Xaeros_Minimap_24.2.1_Fabric_1.21.jar:?]
at xaero.common.HudMod.loadLater(HudMod.java:234) [Xaeros_Minimap_24.2.1_Fabric_1.21.jar:?]
at xaero.minimap.XaeroMinimapFabric.tryLoadLater(XaeroMinimapFabric.java:65) [Xaeros_Minimap_24.2.1_Fabric_1.21.jar:?]
at net.minecraft.class_310.handler$eee002$xaerominimap$onTickStart(class_310.java:28677) [client-intermediary.jar:?]
at net.minecraft.class_310.method_1574(class_310.java) [client-intermediary.jar:?]
at net.minecraft.class_310.method_1523(class_310.java:1246) [client-intermediary.jar:?]
at net.minecraft.class_310.method_1514(class_310.java:882) [client-intermediary.jar:?]
at net.minecraft.client.main.Main.main(Main.java:256) [client-intermediary.jar:?]
at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:470) [fabric-loader-0.15.11.jar:?]
at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:74) [fabric-loader-0.15.11.jar:?]
at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23) [fabric-loader-0.15.11.jar:?]
Caused by: java.net.SocketTimeoutException: Read timed out
at java.base/sun.nio.ch.NioSocketImpl.timedRead(Unknown Source) ~[?:?]
at java.base/sun.nio.ch.NioSocketImpl.implRead(Unknown Source) ~[?:?]
at java.base/sun.nio.ch.NioSocketImpl.read(Unknown Source) ~[?:?]
at java.base/sun.nio.ch.NioSocketImpl$1.read(Unknown Source) ~[?:?]
at java.base/java.net.Socket$SocketInputStream.read(Unknown Source) ~[?:?]
at java.base/java.io.BufferedInputStream.fill(Unknown Source) ~[?:?]
at java.base/java.io.BufferedInputStream.read1(Unknown Source) ~[?:?]
at java.base/java.io.BufferedInputStream.implRead(Unknown Source) ~[?:?]
at java.base/java.io.BufferedInputStream.read(Unknown Source) ~[?:?]
at java.base/sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source) ~[?:?]
at java.base/sun.net.www.http.HttpClient.parseHTTP(Unknown Source) ~[?:?]
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source) ~[?:?]
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) ~[?:?]
at java.base/sun.net.www.protocol.http.HttpURLConnection.getHeaderField(Unknown Source) ~[?:?]
at java.base/java.net.URLConnection.getHeaderFieldLong(Unknown Source) ~[?:?]
at java.base/java.net.URLConnection.getContentLengthLong(Unknown Source) ~[?:?]
at xaero.common.misc.Internet.checkModVersion(Internet.java:53) ~[Xaeros_Minimap_24.2.1_Fabric_1.21.jar:?]
... 10 more
[12:58:51] [Render thread/INFO]: Registered player tracker system: minimap_synced
[12:58:51] [Render thread/INFO]: Xaero's Minimap: World Map found!
[12:58:51] [Render thread/INFO]: No Optifine!
[12:58:51] [Render thread/INFO]: Xaero's Minimap: No Vivecraft!
[12:58:51] [Render thread/INFO]: Xaero's Minimap: Iris found!
[12:58:55] [Render thread/WARN]: Missing sound for event: minecraft:item.goat_horn.play
[12:58:55] [Render thread/WARN]: Missing sound for event: minecraft:entity.goat.screaming.horn_break
[12:58:55] [Render thread/INFO]: OpenAL initialized on device OpenAL Soft on Lautsprecher (2- High Definition Audio Device)
[12:58:55] [Render thread/INFO]: Sound engine started
[12:58:55] [Render thread/INFO]: Created: 1024x1024x0 minecraft:textures/atlas/blocks.png-atlas
[12:58:55] [Render thread/INFO]: Created: 256x256x0 minecraft:textures/atlas/signs.png-atlas
[12:58:55] [Render thread/INFO]: Created: 512x512x0 minecraft:textures/atlas/banner_patterns.png-atlas
[12:58:55] [Render thread/INFO]: Created: 512x512x0 minecraft:textures/atlas/shield_patterns.png-atlas
[12:58:55] [Render thread/INFO]: Created: 1024x1024x0 minecraft:textures/atlas/armor_trims.png-atlas
[12:58:55] [Render thread/INFO]: Created: 256x256x0 minecraft:textures/atlas/chest.png-atlas
[12:58:55] [Render thread/INFO]: Created: 128x64x0 minecraft:textures/atlas/decorated_pot.png-atlas
[12:58:55] [Render thread/INFO]: Created: 512x256x0 minecraft:textures/atlas/beds.png-atlas
[12:58:55] [Render thread/INFO]: Created: 512x256x0 minecraft:textures/atlas/shulker_boxes.png-atlas
[12:58:57] [Render thread/INFO]: Created: 512x256x0 minecraft:textures/atlas/particles.png-atlas
[12:58:57] [Render thread/INFO]: Created: 512x256x0 minecraft:textures/atlas/paintings.png-atlas
[12:58:57] [Render thread/INFO]: Created: 256x128x0 minecraft:textures/atlas/mob_effects.png-atlas
[12:58:57] [Render thread/INFO]: Created: 64x64x0 minecraft:textures/atlas/map_decorations.png-atlas
[12:58:57] [Render thread/INFO]: Created: 1024x512x0 minecraft:textures/atlas/gui.png-atlas
[12:58:57] [Render thread/WARN]: Shader rendertype_entity_translucent_emissive could not find sampler named Sampler2 in the specified shader program.
[12:58:57] [Render thread/INFO]: Shutting down renderer (fabric)
[12:58:57] [Render thread/INFO]: Renderer shutting down.
[12:58:57] [Render thread/INFO]: Starting up renderer (fabric)
[12:58:57] [Render thread/INFO]: Renderer starting up.
[12:58:57] [Render thread/WARN]: Removing existing FSB skies...
[12:58:57] [Render thread/WARN]: FSB-Interop is converting MCPatcher/OptiFine custom skies resource packs! Any visual bugs are likely caused by FSB-Interop. Please do not report these issues to FabricSkyBoxes nor Resource Pack creators!
[12:58:57] [Render thread/INFO]: Looking for OptiFine/MCPatcher Skies...
[12:58:57] [Render thread/INFO]: Loaded GUI modifiers for: [] [] [] []
[12:58:57] [Render thread/INFO]: Reloaded Polytone Resources in 14 ms
[12:58:57] [Render thread/INFO]: Successfully reloaded the minimap shaders!
[12:58:57] [Render thread/INFO]: Successfully reloaded the world map shaders!
[12:58:57] [Render thread/INFO]: Successfully loaded image 'zoomify:textures/demo/third-person-hud.webp'
[12:58:57] [Render thread/INFO]: Successfully loaded image 'zoomify:textures/demo/third-person-view.webp'
[12:58:57] [Render thread/INFO]: Successfully loaded image 'zoomify:textures/demo/zoom-hand.webp'
[12:58:57] [Render thread/INFO]: Successfully loaded image 'zoomify:textures/demo/zoom-world.webp'
[12:58:57] [Render thread/INFO]: Successfully loaded image 'controlify:textures/screenshots/reach-around-placement.webp'
[12:58:57] [Render thread/INFO]: Successfully loaded image 'controlify:textures/screenshots/reduce-aim-sensitivity.webp'
[12:58:57] [Render thread/INFO]: Successfully loaded image 'controlify:textures/screenshots/screen-button-guide.webp'
[12:58:57] [Render thread/INFO]: reloading ETF data.
[12:58:57] [Render thread/INFO]: emissive suffixes loaded: {_e}.
[12:58:57] [Render thread/INFO]: emissive suffixes loaded: {_e}.
[12:58:57] [Render thread/INFO]: Checking for DH update
[12:58:58] [Render thread/INFO]: Creating pipeline for dimension minecraft:overworld
[12:58:58] [Render thread/INFO]: Initializing Controlify...
[12:58:58] [Render thread/INFO]: Loading Controlify config...
[12:59:00] [Render thread/WARN]: Game took 48.01 seconds to start
[12:59:19] [Render thread/INFO]: inventoryessentials.mixins.json:CreativeModeInventoryScreenAccessor from mod inventoryessentials->@Accessor[FIELD_GETTER]::getCONTAINER()Lnet/minecraft/class_1277; should be static as its target is
[12:59:19] [Render thread/INFO]: Adding auth button to the multiplayer screen
[12:59:19] [ForkJoinPool.commonPool-worker-1/INFO]: Verifying Minecraft session...
[12:59:20] [ForkJoinPool.commonPool-worker-1/INFO]: The Minecraft session is valid
[12:59:21] [Render thread/INFO]: Adding auth button to the multiplayer screen
[12:59:22] [Render thread/INFO]: Connecting to mc.azgeda.de, 25576
[12:59:43] [Server Connector #1/ERROR]: Couldn't connect to server
io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection timed out: getsockopt: mc.azgeda.de/<IP_ADDRESS>:25576
Caused by: java.net.ConnectException: Connection timed out: getsockopt
at java.base/sun.nio.ch.Net.pollConnect(Native Method) ~[?:?]
at java.base/sun.nio.ch.Net.pollConnectNow(Unknown Source) ~[?:?]
at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source) ~[?:?]
at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:337) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:334) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:776) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) ~[netty-transport-4.1.97.Final.jar:?]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.97.Final.jar:?]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.97.Final.jar:?]
at java.base/java.lang.Thread.run(Unknown Source) ~[?:?]
[12:59:48] [Render thread/INFO]: Adding auth button to the multiplayer screen

I believe it is an issue with this docker deployment and not forge directly because I’ve had no issue setting up forge servers using pterodactyl containers on the new versions, and old versions of this container work fine. It’s just the new versions that had these issues.


How to connect to host MySQL server without using MySQL Docker container

Hello,
I'm running the latest Docker for Mac on OSX Yosemite.  I have a MySQL server running on my Mac.  Let's call my local machine my "Mac host."  Thus, Laradock is running on top of Docker for Mac, which is running on top of my Mac host.
From my Laradock instance, I want to connect to this MySQL server / database on my Mac host.  I've tried using "volumes" with the MySQL Laradock Docker container, and it works, but I wonder if it's slower than connecting to a "remote" MySQL server running on my Mac host.
The problem is, I'm not sure how to configure this.  It seems like the Docker containers all think that <IP_ADDRESS> or "localhost" lives within their container, and I don't know how to tell them to look outside their container at the IP address of my Mac host to connect to the MySQL server.
I've looked at the Docker Compose documentation, and I can't seem to find anywhere how to do this using port mapping/forwarding, extra hosts, networks, proxies, etc.
Can somebody please tell me how to connect to the MySQL server running on my Mac host from the Laradock Docker containers?

Hi,
I'm not using Laradock but I got the same issue with my container and here is my solution:
try to ifconfig on your mac, and you will see your host ip address, in my case it's <IP_ADDRESS>

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether d0:a6:37:eb:13:15
inet6 fe80::d2a6:37ff:feeb:1315%en0 prefixlen 64 scopeid 0x4
inet <IP_ADDRESS> netmask 0xffffff00 broadcast <IP_ADDRESS>
...

use that ip address as mysql host, see if it can help
(side comment: I found that docker-for-mac 1.12 is very slow compare to docker-machine)

Where do I specify the IP address that you mention?


Fixing paths for nested sub commands in calls to load_subcommand.

Fixes an issue in PR 1093 where paths are incorrect for some nested sub commands.

BTW I noticed that the kontena stack registry command isn't using the subcommand_loader either... want to fix that too at the same time?

@SpComb: I updated stack registry

BTW you don't need to write out the [PR xyz](...) links, you can just write #1093.


attic check with ATTIC_PASSPHRASE -- getpass.py/terminal issue

I run attic check from cron (daily while testing, once a week in future).  Attic uses a $ATTIC_PASSPHRASE set in the environment.  This is running from cron.
attic check does the repository check OK but when it does the archive consistency check it fails with:
Starting repository check...
Repository check complete, no problems found.
Starting archive consistency check...
/usr/lib/python3.4/getpass.py:92: GetPassWarning: Can not control echo on the terminal.
  passwd = fallback_getpass(prompt, stream)
Warning: Password input may be echoed.
Enter passphrase for /backup/attic/work-backup.attic: Traceback (most recent call last):
  File "/usr/lib/python3.4/getpass.py", line 70, in unix_getpass
    old = termios.tcgetattr(fd)     # a copy to save
termios.error: (25, 'Inappropriate ioctl for device')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/attic", line 3, in <module>
    main()
  File "/usr/local/lib/python3.4/dist-packages/attic/archiver.py", line 730, in main
    exit_code = archiver.run(sys.argv[1:])
  File "/usr/local/lib/python3.4/dist-packages/attic/archiver.py", line 720, in run
    return args.func(args)
  File "/usr/local/lib/python3.4/dist-packages/attic/archiver.py", line 85, in do_check
    if not args.repo_only and not ArchiveChecker().check(repository, repair=args.repair):
  File "/usr/local/lib/python3.4/dist-packages/attic/archive.py", line 542, in check
    self.key = self.identify_key(repository)
  File "/usr/local/lib/python3.4/dist-packages/attic/archive.py", line 576, in identify_key
    return key_factory(repository, cdata)
  File "/usr/local/lib/python3.4/dist-packages/attic/key.py", line 45, in key_factory
    return PassphraseKey.detect(repository, manifest_data)
  File "/usr/local/lib/python3.4/dist-packages/attic/key.py", line 187, in detect
    passphrase = getpass(prompt)
  File "/usr/lib/python3.4/getpass.py", line 92, in unix_getpass
    passwd = fallback_getpass(prompt, stream)
  File "/usr/lib/python3.4/getpass.py", line 127, in fallback_getpass
    return _raw_input(prompt, stream)
  File "/usr/lib/python3.4/getpass.py", line 149, in _raw_input
    raise EOFError
EOFError

Is this a known issue and is there a command line parameter or environment variable or similar that I can set to make getpass.py not break when it thinks it's not talking to a terminal?
I think I could possibly get this working if I set up ssh key auth and have the cron job ssh to localhost to run attic-check.  I'll test that (haven't yet) if there is no more standard way to fix.
Gerald Quimpo

        passphrase = os.environ.get('ATTIC_PASSPHRASE')
        if passphrase is None:
            passphrase = getpass(prompt)  # this is line 187

That means you did not set ATTIC_PASSPHRASE.
If you did, it would not execute that line.

Thank you Thomas.  After further investigation, I had a misunderstanding about how exporting a variable in a sourced script.  The variable would be available to subshells, but not to the calling shell :-).  I've changed how the attic passphrase env variable is initialized and it's now available to attic check.
I was confused since there was this:
Starting repository check...
Repository check complete, no problems found.

I'd assumed that repository check would also require the passphrase.  but it looks like it doesn't since that succeeded and only the archive checks failed.


Bug: Header values should not be lowercased

Describe the bug
Headers keys and values are lowercased before being rendered. While lowercasing key is fine (as per HTTP2 spec), lowercasing values should not be done.
For my use case, integrating with a payment provider involves passing a transaction ID as a header. This ID contains lowercase, uppercase letters, and is not case-insensitive.
To Reproduce

Create a new route_handler.
In the route_handler, modify the response: response.headers["Foo"] = "Bar" .
Observe that the key and value are returned as lowercase:

While reporting this, I noticed that date and vary headers are not lowercased.

Additional context
Looking at the Git history, it seems that originally Starlette was used for handling the responses. I thought that Starlette might also have this behaviour, but they do not lowercase the header values. See https://github.com/encode/starlette/blob/fa737beb2838f568fe2477e2316a7fdf3d3eb257/starlette/responses.py#L72 .
The relevant code in Starlite is here: https://github.com/starlite-api/starlite/blob/95379f102be249f3c9453fbf9d216a41eede2d6f/starlite/response/base.py#L257

yup, will fix. @provinzkraut can you take this on quickly and add it to the release you are doing?

@Goldziher will do. Just waiting for a comment from you on the open conversations, then it's ready to go

@LordGaav Thanks for reporting! It's fixed in #695 and will be in the next release!

That was quick, thanks 👍


How to explain the result of tf.map_fn?

item_map = {223368: 2, 227300: 3}
i =tf.reshape([223368,223368], [-1, ])
o1 = tf.map_fn(lambda x: item_map.get(x, 0),i)
o2 = tf.map_fn(lambda x: item_map.get(223368, 0), i)
o3 = tf.map_fn(lambda x:x, i)
with tf.Session() as sess:
    sess.run(tf.global_variables_initializer())
    print(i.eval())  #输出[223368 223368]
    print(o1.eval()) #输出[0 0]
    print(o2.eval()) #输出[2 2]
    print(o3.eval()) #输出[223368 223368]

why o1 is [0,0]?

@xueyuan1990
the code shared is incomplete for us to replicate it, please share complete standalone code.
As your question is related to understanding tf.map_fn, please refer to this link and let us know if it helps.
link2 ,
link3 ,
link4

@xueyuan1990
please update as per above comment

Automatically closing due to lack of recent activity. Please update the issue when new information becomes available, and we will reopen the issue. Thanks!


efilrst:0.2.0

I am submitting

[ ] a new package
[x] an update for a package

Description: A package that allows to reference list elements.

I have read and followed the submission guidelines and, in particular, I

[x] selected a name that isn't the most obvious or canonical name for what the package does
[x] added a typst.toml file with all required keys
[x] added a README.md with documentation for my package
[x] have chosen a license and added a LICENSE file or linked one in my README.md
[x] tested my package locally on my system and it worked
[x] excluded PDFs or README images, if any, but not the LICENSE

[x] ensured that my package is licensed such that users can use and distribute the contents of its template directory without restriction, after modifying them through normal use.

Thanks


Selecting a specific key doesn't show up in Environment From Sources in workload details

Rancher versions: 2.0 master 4/18
Steps to Reproduce:

Create a config or secret
Create a workload and add it to the environment section and change Key from All to the specific key
Launch workload
Go to workload details

Results:  The Key is not showing up

UI sends sourceKey field to backend. But backend doesn't populate this field. It was working few days ago.

@logan - this was being saved to the API yesterday and still wasn't showing up.

Version - 2.0 master 4/26
Verified fixed


Poster generation: Set video as the poster's parent

Summary
Poster generation: Set video as the poster's parent
Relevant Technical Choices
Add a new param to set parent of attachment on update.
To-do

User-facing changes

Testing Instructions

Fixes #5544

Could you elaborate on why a new param was needed? Because of the limitations outlined on the ticket? Just so it‘s documented...
Also, should there be some check that the parent is actually an attachment? Right now it could be anything.


error checking with proteogenomics data

better edge case errors for proteogenomic data

sample with only 1 analyte in data !all(names(data) %in% names(probeAssay))

Sample with only 1 analyte has been determined to be an outlier, will not be common to not have a single RTSID attributed to RNA.


az pipelines list top defaults to 10000

When calling az pipelines list, top defaults to 10,000.  The documentation should say this so we know we have to specify --top if we want more records than 10,000.

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

ID: 66f0311f-8316-ea52-6171-9eb14b9f7bc7
Version Independent ID: e79f2bc9-543d-9a14-a08c-911d037e108a
Content: az pipelines
Content Source: latest/docs-ref-autogen/pipelines.yml
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

Thank you for opening this issue, we will look into it.