NOTE
If your issue is for security or deals with sensitive info please mark it as private using the checkbox below.
For a package with the + character in its name, like https://src.fedoraproject.org/rpms/libsigc++30, following the “Builds Status” link, e.g. https://koji.fedoraproject.org/koji/search?type=package&match=glob&terms=libsigc++30, gives zero results because (as we can see in the “Search” text box), the + characters are turned into spaces. In this case, hand-editing the “Search” text box to restore the + characters gives the correct results, e.g. https://koji.fedoraproject.org/koji/packageinfo?packageID=29928.
+
Similarly, following the “Updates Status” link, e.g. https://bodhi.fedoraproject.org/updates/?packages=libsigc++30, gives zero results, and we can see that the applied filter is e.g. packages: libsig 30, so a similar substitution has taken place. Searching manually for the package name in the top-level search box (not the one in the header row of the empty results table) gives the correct result, e.g. https://bodhi.fedoraproject.org/updates/?packages=libsigc%2B%2B30.
packages: libsig 30
We can see that the “Bug Reports” link is also broken: libsigc++30 doesn’t have any open bugs, but https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=libsigc%20%2030&product=Fedora&product=Fedora%20EPEL contains component=libsigc%20%2030, and %20 encodes the space character, not +, so this is wrong as well.
libsigc++30
component=libsigc%20%2030
%20
The “Packages” and “Koschei Status” links still work, e.g. https://packages.fedoraproject.org/pkgs/libsigc++30/ and https://koschei.fedoraproject.org//package/libsigc++30.
I know that this used to work, and I think that it broke very recently. When you have time, please investigate the cause and make the necessary change to repair these links.
No deadline; this is an annoyance, but it is not blocking work.
Could you file a ticket upstream? We are closing this, but feel free to reopen if necessary
Metadata Update from @phsmoura: - Issue close_status updated to: Upstream - Issue status updated to: Closed (was: Open)
try to file a ticket at pagure-dist-git
Looking at this a bit more, I know that this was not triggered by a change in pagure-dist-git, because the last commit to pagure-dist-git was ten months ago, and I believe this problem to be much more recent.
pagure-dist-git
However, I think I now basically understand the problem. The URLs associated with the “Builds Status,” “Updates Status,” and “Bug Reports” buttons on the dist-git project page, e.g. https://src.fedoraproject.org/rpms/libsigc++20, all have the + character in them, and in all cases it’s in the query string. (In “Packages” and “Koschei,” which aren’t broken, the package name with + characters is not in the query string.) It turns out that per https://www.w3.org/Addressing/URL/uri-spec.html, “Within the query string, the plus sign is reserved as shorthand notation for a space. Therefore, real plus signs must be encoded. This method was used to make query URIs easier to pass in systems which did not allow spaces.” It seems like something somewhere – maybe in a proxy? – has started to implement this feature, and so we’re ending up with broken package names after we actually follow these links.
The fix will therefore need to be in https://pagure.io/pagure itself, in the form of applying the urlencode jinja2 filter when forming URLs with repo.name, e.g. here for “Updates Status.” I’ll open a PR.
urlencode
jinja2
repo.name
https://pagure.io/pagure/pull-request/5528
Log in to comment on this ticket.