Error 500 in package view after uploading pypi package #9700

New Issue

GiteaMirror · 2025-11-02T08:47:00-06:00

GiteaMirror commented

2025-11-02 08:47:00 -06:00

Originally created by @gd197 on GitHub (Oct 18, 2022).

Description

Error 500 is shown when trying to get list of package for an organization.
This occurred after uploading some python packages (wheels) with twine.
Logs show this error:
2022/10/18 08:27:00 .../web/user/package.go:58:ListPackages() [E] [634e4734-29] GetPackageDescriptors: pypi.Metadata.Description: readStringSlowPath: unexpected end of input, error found in #10 byte of ...|coon:\")\n|..., bigger context ...|:vampire: :pile_of_poo: :thumbs_up: :raccoon:\")\n|...
I created this ticket to not forget but I'm still checking what could have been happened, I will update the ticket accordingly.
First feeling is that a user tried to upload a corrupted package.

Gitea Version

1.17.1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.27

Operating System

RHEL7

How are you running Gitea?

executable from GitHub delivery

Database

MySQL

Originally created by @gd197 on GitHub (Oct 18, 2022). ### Description Error 500 is shown when trying to get list of package for an organization. This occurred after uploading some python packages (wheels) with twine. Logs show this error: ` 2022/10/18 08:27:00 .../web/user/package.go:58:ListPackages() [E] [634e4734-29] GetPackageDescriptors: pypi.Metadata.Description: readStringSlowPath: unexpected end of input, error found in #10 byte of ...|coon:\")\n|..., bigger context ...|:vampire: :pile_of_poo: :thumbs_up: :raccoon:\")\n|... ` I created this ticket to not forget but I'm still checking what could have been happened, I will update the ticket accordingly. First feeling is that a user tried to upload a corrupted package. ### Gitea Version 1.17.1 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.27 ### Operating System RHEL7 ### How are you running Gitea? executable from GitHub delivery ### Database MySQL

GiteaMirror added the topic/packages type/bug labels 2025-11-02 08:47:00 -06:00

GiteaMirror closed this issue

2025-11-02 08:47:00 -06:00

GiteaMirror commented

2025-11-02 08:47:01 -06:00

@lunny commented on GitHub (Oct 18, 2022):

Could you try to upgrade to v1.17.3?

@lunny commented on GitHub (Oct 18, 2022): Could you try to upgrade to v1.17.3?

GiteaMirror commented

2025-11-02 08:47:01 -06:00

@gd197 commented on GitHub (Oct 18, 2022):

Yep that is my plan, will do that in the next coming hours.

@gd197 commented on GitHub (Oct 18, 2022): Yep that is my plan, will do that in the next coming hours.

GiteaMirror commented

2025-11-02 08:47:01 -06:00

@gd197 commented on GitHub (Oct 18, 2022):

same issue on 1.17.3 :(

@gd197 commented on GitHub (Oct 18, 2022): same issue on 1.17.3 :( ![image](https://user-images.githubusercontent.com/25028540/196392860-e8fcbe1e-ddc3-4727-9f6e-7052b71749ac.png)

GiteaMirror commented

2025-11-02 08:47:01 -06:00

@gd197 commented on GitHub (Oct 18, 2022):

one of these wheels caused the issue

bleach-5.0.1
commonmark-0.9.1
readme_renderer-37.2
rfc3986-2.0.0
rich-12.6.0
twine-4.0.1
wheel-0.37.1

I'm setting up a new instance to reproduce

@gd197 commented on GitHub (Oct 18, 2022): one of these wheels caused the issue - bleach-5.0.1 - commonmark-0.9.1 - readme_renderer-37.2 - rfc3986-2.0.0 - rich-12.6.0 - twine-4.0.1 - wheel-0.37.1 I'm setting up a new instance to reproduce

GiteaMirror commented

2025-11-02 08:47:02 -06:00

@gd197 commented on GitHub (Oct 18, 2022):

the package causing the issue is rich-12.6.0
81ac2e7d1e/rich-12.6.0-py3-none-any.whl
still checking whether the dl from user was not corrupted

@gd197 commented on GitHub (Oct 18, 2022): the package causing the issue is rich-12.6.0 https://files.pythonhosted.org/packages/32/60/81ac2e7d1e3b861ab478a72e3b20fc91c4302acd2274822e493758941829/rich-12.6.0-py3-none-any.whl still checking whether the dl from user was not corrupted

GiteaMirror commented

2025-11-02 08:47:02 -06:00

@gd197 commented on GitHub (Oct 18, 2022):

no issue / not reproducible in a new 1.17.1 environment.
Looks like there were an issue when the user dl the package from pypi or when publishing it with twine in gitea.
Nevertheless, it is not possible to delete the package in the gitea registry nor updating it.

@gd197 commented on GitHub (Oct 18, 2022): no issue / not reproducible in a new 1.17.1 environment. Looks like there were an issue when the user dl the package from pypi or when publishing it with twine in gitea. Nevertheless, it is not possible to delete the package in the gitea registry nor updating it.

GiteaMirror commented

2025-11-02 08:47:02 -06:00

@gd197 commented on GitHub (Oct 18, 2022):

here is a snapshot of the metadata rendered by gitea in the working instance.
please note that according to the log, gitea is failing after the
>>> console.print comment.
Note also that external png references are rendered out of the box

@gd197 commented on GitHub (Oct 18, 2022): here is a snapshot of the metadata rendered by gitea in the working instance. please note that according to the log, gitea is failing after the `>>> console.print ` comment. Note also that external png references are rendered out of the box ![image](https://user-images.githubusercontent.com/25028540/196404629-ce7b8d40-9a0f-4bfe-aaad-a6d3e1c92565.png)

GiteaMirror commented

2025-11-02 08:47:02 -06:00

@lunny commented on GitHub (Oct 18, 2022):

Did you use utf8mb4 in your MySQL?

@lunny commented on GitHub (Oct 18, 2022): Did you use utf8mb4 in your MySQL?

GiteaMirror commented

2025-11-02 08:47:03 -06:00

@gd197 commented on GitHub (Oct 18, 2022):

CHARSET is utf8 in gitea.ini in the instance where issue appear
and is not set in the ini file of the correct one indeed there is a diff there

@gd197 commented on GitHub (Oct 18, 2022): CHARSET is utf8 in gitea.ini in the instance where issue appear and is not set in the ini file of the correct one indeed there is a diff there

GiteaMirror commented

2025-11-02 08:47:03 -06:00

@gd197 commented on GitHub (Oct 18, 2022):

The database where the issue occurs looks correctly set to utf8mb4 anyways

MariaDB [(none)]> SELECT * FROM INFORMATION_SCHEMA.SCHEMATA;
+--------------+--------------------+----------------------------+------------------------+----------+
| CATALOG_NAME | SCHEMA_NAME        | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME | SQL_PATH |
+--------------+--------------------+----------------------------+------------------------+----------+
| def          | information_schema | utf8                       | utf8_general_ci        | NULL     |
| def          | gitea              | utf8mb4                    | utf8mb4_unicode_ci     | NULL     |

GiteaMirror commented

2025-11-02 08:47:04 -06:00

@lunny commented on GitHub (Oct 18, 2022):

Keep database as utf8mb4 and gitea.ini as utf8mb4 both.

@lunny commented on GitHub (Oct 18, 2022): Keep database as utf8mb4 and gitea.ini as utf8mb4 both.

GiteaMirror commented

2025-11-02 08:47:04 -06:00

@gd197 commented on GitHub (Oct 18, 2022):

yep thanks for the hint, i saw my mistake, probably due to the fact that I setup this database years ago.
I wonder whether I need to convert tables from utf8 to utf8mb4 or if it's enough to set the app.ini CHARSET entry to utf8mb4

@gd197 commented on GitHub (Oct 18, 2022): yep thanks for the hint, i saw my mistake, probably due to the fact that I setup this database years ago. I wonder whether I need to convert tables from utf8 to utf8mb4 or if it's enough to set the app.ini CHARSET entry to utf8mb4

GiteaMirror commented

2025-11-02 08:47:04 -06:00

@lunny commented on GitHub (Oct 18, 2022):

If your database tables are utf8, you need to convert them to utf8mb4. Gitea also provide a command ./gitea convert to help to do that. You should also set app.ini CHARSET entry as utf8mb4. You should change both.

@lunny commented on GitHub (Oct 18, 2022): If your database tables are utf8, you need to convert them to utf8mb4. Gitea also provide a command `./gitea convert` to help to do that. You should also set app.ini CHARSET entry as utf8mb4. You should change both.

GiteaMirror commented

2025-11-02 08:47:05 -06:00

@gd197 commented on GitHub (Oct 19, 2022):

my issue is :
database is utf8mb4 but CHARSET in app.ini is utf8 I fear we corrupted the metadata entry for the mentioned package.

@gd197 commented on GitHub (Oct 19, 2022): my issue is : database is utf8mb4 but CHARSET in app.ini is utf8 I fear we corrupted the metadata entry for the mentioned package.

GiteaMirror commented

2025-11-02 08:47:05 -06:00

@lunny commented on GitHub (Oct 19, 2022):

my issue is : database is utf8mb4 but CHARSET in app.ini is utf8 I fear we corrupted the metadata entry for the mentioned package.

Then you can just change app.ini CHARSET to utf8mb4 and restart Gitea

@lunny commented on GitHub (Oct 19, 2022): > my issue is : database is utf8mb4 but CHARSET in app.ini is utf8 I fear we corrupted the metadata entry for the mentioned package. Then you can just change app.ini CHARSET to utf8mb4 and restart Gitea

GiteaMirror commented

2025-11-02 08:47:05 -06:00

@gd197 commented on GitHub (Oct 19, 2022):

ok done, but we have still the issue for the mentioned package.
API is working fine for publishing/downloading packages but the GUI is crashing.
My understanding is that we have corrupted the metadata entry for this package (which was containing encoded emojis characters).
As far as I can see, there is no API for deleting a package, meaning that we should do it manually in database.

@gd197 commented on GitHub (Oct 19, 2022): ok done, but we have still the issue for the mentioned package. API is working fine for publishing/downloading packages but the GUI is crashing. My understanding is that we have corrupted the metadata entry for this package (which was containing encoded emojis characters). As far as I can see, there is no API for deleting a package, meaning that we should do it manually in database.

GiteaMirror commented

2025-11-02 08:47:06 -06:00

@KN4CK3R commented on GitHub (Oct 20, 2022):

You could manually navigate to /<owner>/-/packages/<type>/<name>/<version>/settings to delete the package.

As far as I can see, there is no API for deleting a package, meaning that we should do it manually in database.

There is an API call for that: https://gitea.com/api/swagger#/package/deletePackage

And as a third way, you can delete a package from the admin dashboard /admin/packages.

@KN4CK3R commented on GitHub (Oct 20, 2022): You could manually navigate to `/<owner>/-/packages/<type>/<name>/<version>/settings` to delete the package. > As far as I can see, there is no API for deleting a package, meaning that we should do it manually in database. There is an API call for that: https://gitea.com/api/swagger#/package/deletePackage And as a third way, you can delete a package from the admin dashboard `/admin/packages`.

GiteaMirror commented

2025-11-02 08:47:06 -06:00

@lunny commented on GitHub (Mar 25, 2024):

I think this could be closed as it's caused by mixed configuration.

@lunny commented on GitHub (Mar 25, 2024): I think this could be closed as it's caused by mixed configuration.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9700