Please see: https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits

You must use fedpkg to clone or push (so it can add the token setup to your git config) and you must have a gui session so it can open a browser (for you to get that token)

Please see: https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits
You must use fedpkg to clone or push (so it can add the token setup to your git config) and you must have a gui session so it can open a browser (for you to get that token)

@jjames Closing the ticket, please reopen the ticket if the problem still persists after trying above mentioned instructions.

The documentation is inadequate. Specifically:

• The documentation is not discoverable. The HTTPS-commits URL above is not to be found anywhere on pagure.io or src.fedoraproject.org, meaning that those trying to figure out how to interact these systems cannot find it. Please add that URL in a prominent place on both. Google found https://docs.fedoraproject.org/en-US/ci/pull-requests/ for me; that also should be visible somewhere. Probably HTTPS-commits should point to it.
• Both the HTTPS-commits document and the responses above refer to cloning pagure repositories with fedpkg, but don't say how that is to be done with repos on pagure.io. The form used on the pull-requests document works for src URLS, but not for pagure.io URLs, as fedpkg tacks https://src.fedoraproject.org/ onto the beginning. Please update the documentation with a complete example of how to do this with a forked pagure.io repository.
• The HTTPS-commits document refers to using a "recent enough fedpkg", leaving a packager no way of determining whether the fedpkg (s)he has at hand is recent enough. Please change that phrase to refer to a specific fedpkg version number. I have fedpkg-1.37-13.fc31. is that "recent enough"?
• The HTTPS-commits document does not explain why pagure and src have different API token lists on the settings pages, nor do any of the comments above. Please explain this in the documentation.
• As others have complained on fedora-devel-list, the API token page in settings on pagure does not say where the token is supposed to be stored. Please update that page so that it specifically says that the token goes in ~/.config/rpkg/fedpkg.conf under [fedpkg.pagure], with an example.
• The API token page in settings on src should also say where the token is supposed to be stored. I do not recall seeing any message on fedora-devel-list that talks about that token at all, so I have no idea what to do with it. Please update that page so that it specifically says where the token should be stored, with an example.

I did manage to make a pull request for ocaml-lwt, by the way. But now I wish to push to a forked FedoraReview repo and cannot figure out how to check it out with fedpkg. After doing a plain git checkout, both "fedpkg push" and "git push" return an HTTP 403 response.

The documentation is inadequate. Specifically:

The documentation is not discoverable. The HTTPS-commits URL above is not to be found anywhere on pagure.io or src.fedoraproject.org, meaning that those trying to figure out how to interact these systems cannot find it. Please add that URL in a prominent place on both. Google found https://docs.fedoraproject.org/en-US/ci/pull-requests/ for me; that also should be visible somewhere. Probably HTTPS-commits should point to it.

Yes, it should be mentioned on src.fedoraproject.org.

Currently pagure.io does not support https pushing (but it's planned).

Both the HTTPS-commits document and the responses above refer to cloning pagure repositories with fedpkg, but don't say how that is to be done with repos on pagure.io. The form used on the pull-requests document works for src URLS, but not for pagure.io URLs, as fedpkg tacks https://src.fedoraproject.org/ onto the beginning. Please update the documentation with a complete example of how to do this with a forked pagure.io repository.

You cannot. pagure.io doesn't support https pushing.

The HTTPS-commits document refers to using a "recent enough fedpkg", leaving a packager no way of determining whether the fedpkg (s)he has at hand is recent enough. Please change that phrase to refer to a specific fedpkg version number. I have fedpkg-1.37-13.fc31. is that "recent enough"?'

yes. The change was actually in rpkg, and fedpkg 1.34 was the one that required it.

The HTTPS-commits document does not explain why pagure and src have different API token lists on the settings pages, nor do any of the comments above. Please explain this in the documentation.

They are completely seperate pagure instances. They are using the same software, but are completely different instances.

As others have complained on fedora-devel-list, the API token page in settings on pagure does not say where the token is supposed to be stored. Please update that page so that it specifically says that the token goes in ~/.config/rpkg/fedpkg.conf under [fedpkg.pagure], with an example.

Needs a pagure.io/pagure ticket/issue I guess? fedpkg does mention it tho...

The API token page in settings on src should also say where the token is supposed to be stored. I do not recall seeing any message on fedora-devel-list that talks about that token at all, so I have no idea what to do with it. Please update that page so that it specifically says where the token should be stored, with an example.

fedpkg takes care of that for you. You do not need to manually store it anywhere.

I did manage to make a pull request for ocaml-lwt, by the way. But now I wish to push to a forked FedoraReview repo and cannot figure out how to check it out with fedpkg. After doing a plain git checkout, both "fedpkg push" and "git push" return an HTTP 403 response.

If thats on pagure.io, it doesn't support https pushing (yet).

We should file the needed tickets here and try and improve docs.

Sorry, didn't mean to clear that tag and re-assign it... not sure why it did that. ;(

Filed https://pagure.io/pagure/issue/5124

Currently pagure.io does not support https pushing (but it's planned).

It does support and it is enabled.

src.fp.o does but not with the same mechanism as pagure's API-token based way conflicts with dist-git's OIDC-token based one.