fedpkg fork broken?

[Richard Shaw]

I'm trying this for the first time (hadn't even noticed it was there!).
I've been using the src.fp.o github style forking from the web.

I cloned a random project of mine and then tried:
$ fedpkg fork
Could not execute do_distgit_fork: The following error occurred while
creating a new fork: Invalid or expired token. Please visit
https://src.fedoraproject.org/settings#nav-api-tab to get or renew your API
token.
For invalid or expired token refer to "fedpkg fork -h" to set a token in
your user configuration.

I checked src.fp.o/settings and even though my key was still valid, it was
going to expire this month so I went ahead and generated a new api token
and saved it in the specified location:
~/.config/rpkg/fedpkg.conf

But I still get the same message 10 minutes later.

GRIPE: You can't actually see the whole key in the website even though I'm
on a 1080p monitor and have a ton of whitespace on either side. So I copied
and pasted it again. No dice.

Thanks,
Richard

[Dominique Martinet]

Richard Shaw wrote on Mon, May 18, 2020:
> I checked src.fp.o/settings and even though my key was still valid, it was
> going to expire this month so I went ahead and generated a new api token
> and saved it in the specified location:
> ~/.config/rpkg/fedpkg.conf

I actually hadn't used it yet, so tried just now.
Seems to work for me:

$ fedpkg fork
Fork of the repository has been created: https://src.fedoraproject.org/fork/martinetd/kernel-tools
$ git remote -v
martinetd ssh://[e-mail]/forks/martinetd/rpms/kernel-tools.git (fetch)
martinetd ssh://[e-mail]/forks/martinetd/rpms/kernel-tools.git (push)
origin  ssh://[e-mail]/rpms/kernel-tools (fetch)
origin  ssh://[e-mail]/rpms/kernel-tools (push)

so to answer your question on the other thread, it operates in place and
adds a remote. Exactly what I would have wanted :)

Regarding your problem, did you add the ACL "Fork a project" on your API
key?
I didn't wait after creating it.
> GRIPE: You can't actually see the whole key in the website even though I'm
> on a 1080p monitor and have a ton of whitespace on either side. So I copied
> and pasted it again. No dice.

I agree on this one. Double-clicking worked though, whole key was in
selection on firefox.

fedora 32 with updates-testing enabled if this matters.

Cheers,

[Richard Shaw]

On Mon, May 18, 2020 at 7:25 AM Dominique Martinet 
wrote:
> Richard Shaw wrote on Mon, May 18, 2020:
> > I checked src.fp.o/settings and even though my key was still valid, it
>
> was
> > going to expire this month so I went ahead and generated a new api token
> > and saved it in the specified location:
> > ~/.config/rpkg/fedpkg.conf
>
> I actually hadn't used it yet, so tried just now.
> Seems to work for me:

Don't know what's wrong then...
> $ fedpkg fork
> Fork of the repository has been created:
> https://src.fedoraproject.org/fork/martinetd/kernel-tools
> $ git remote -v
> martinetd ssh://
> [e-mail]/forks/martinetd/rpms/kernel-tools.git (fetch)
> martinetd ssh://
> [e-mail]/forks/martinetd/rpms/kernel-tools.git (push)
> origin  ssh://[e-mail]/rpms/kernel-tools (fetch)
> origin  ssh://[e-mail]/rpms/kernel-tools (push)
>
> so to answer your question on the other thread, it operates in place and
> adds a remote. Exactly what I would have wanted :)

Ok, so this is the opposite workflow where you only clone the main repo and
create a remote for your fork. Would be nice if this was documented but
google didn't turn up anything useful for me. The only documentation I
could find still says to do the opposite. Clone your fork and add the
original as the remote (github style).
> Regarding your problem, did you add the ACL "Fork a project" on your API
> key?

Toggled everything on, went back and verified.

Thanks,
Richard

[Dominique Martinet]

Richard Shaw wrote on Mon, May 18, 2020:
> > Seems to work for me:
>
> Don't know what's wrong then...

I went back and re-read your first mail, it is possible it doesn't work
on one of your own projects?
I'm not sure how much sense there is in forking your own repo...
> Ok, so this is the opposite workflow where you only clone the main repo and
> create a remote for your fork. Would be nice if this was documented but
> google didn't turn up anything useful for me. The only documentation I
> could find still says to do the opposite. Clone your fork and add the
> original as the remote (github style).

Well you have to clone *something* so fedpkg would know what to fork.
I've just done a "fedpkg clone" of a repo to look at it, then assumed
fork would do what hitting fork does on the web ui and this is pretty
close.
I wouldn't want the command to change what origin is, although I'm not
sure how `fedpkg push` works I intended to use plain git commands for
that...

OTOH something did not work, the remote was setup for
ssh://[e-mail]/... and I had assumed there is a magic
account with all ssh public keys that does redirection (like github
does, everything happens under user 'git') but that didn't work; I had
to change the url to specify my user.
I might need to specify --user xyz next time...

[Richard Shaw]

On Mon, May 18, 2020 at 7:59 AM Dominique Martinet 
wrote:
> Richard Shaw wrote on Mon, May 18, 2020:
> > > Seems to work for me:
> >
> > Don't know what's wrong then...
>
> I went back and re-read your first mail, it is possible it doesn't work
> on one of your own projects?
> I'm not sure how much sense there is in forking your own repo...

It can be useful if you want to work outside of dist-git on something that
may be experimental and you don't want to pollute your repo with commits it
that ultimately doesn't work out. Then when done you can submit a pull
request to yourself :)

Thanks,
Richard

[Aleksandra Fedorova]

On Mon, 18 May 2020, 14:18 Richard Shaw,  wrote:
> I'm trying this for the first time (hadn't even noticed it was there!).
> I've been using the src.fp.o github style forking from the web.
>
> I cloned a random project of mine and then tried:
> $ fedpkg fork
> Could not execute do_distgit_fork: The following error occurred while
> creating a new fork: Invalid or expired token. Please visit
> https://src.fedoraproject.org/settings#nav-api-tab to get or renew your
> API token.
> For invalid or expired token refer to "fedpkg fork -h" to set a token in
> your user configuration.
>
> I checked src.fp.o/settings and even though my key was still valid, it was
> going to expire this month so I went ahead and generated a new api token
> and saved it in the specified location:
> ~/.config/rpkg/fedpkg.conf
>
> But I still get the same message 10 minutes later.

I've got the same problem. I think it uses wrong remote path:

[e-mail]

Maybe it was working before, but then certain update happened.

If you check clone options in UI in Pagure interface, the url will look
like:

ssh://[e-mail]/forks/bookwar/rpms/minetest.git

There is no variant with "any".

The API token is valid and works, as the fork is created. It is only the
remote path which is broken.

So I ended up calling git remote explicitly after the fork command to
change the remote uri.

And I think forking your own repo for pull-requests makes perfect sense,
especially since distgit doesn't allow you to remove temporary branches
from the main repo.

--
Aleksandra Fedorova
bookwar

[Kevin Fenzi]

On Sat, May 23, 2020 at 02:19:07AM +0200, Aleksandra Fedorova wrote:
> I've got the same problem. I think it uses wrong remote path:
>
> [e-mail]
>
> Maybe it was working before, but then certain update happened.

So, just to clarify a confusing situation... :)

[e-mail] should never have worked.

If you have pkgs.fedoraproject.org it means you are using SSH, and are a
packager. This is just due to the way pkgs was created. Packagers have
accounts there and can ssh, if you aren't a packager you don't have an
account and can't ssh.

If you see src.fedoraproject.org that means you are using https. 
Anyone with an account can use this (but it needs you to use fedpkg at
least initially to get a token to push your changes).
> If you check clone options in UI in Pagure interface, the url will look
> like:
>
> ssh://[e-mail]/forks/bookwar/rpms/minetest.git
>
> There is no variant with "any".
>
> The API token is valid and works, as the fork is created. It is only the
> remote path which is broken.
>
> So I ended up calling git remote explicitly after the fork command to
> change the remote uri.
>
> And I think forking your own repo for pull-requests makes perfect sense,
> especially since distgit doesn't allow you to remove temporary branches
> from the main repo.

+1

kevin

[Richard Shaw]

I figured out my problem, it's the whole confusing what's part of
src.fedoraproject.org and what's part of pagure.io... You need both tokens
for different actions but one goes in:

[fedpkg.pagure]
token = <paguire.io token>

[fedpkg.distgit]
token = <src.fp.o token>

Thanks,
Richard

[Dominique Martinet]

Kevin Fenzi wrote on Fri, May 22, 2020:
> So, just to clarify a confusing situation... :)
>
> [e-mail] should never have worked.
>
> If you have pkgs.fedoraproject.org it means you are using SSH, and are a
> packager. This is just due to the way pkgs was created. Packagers have
> accounts there and can ssh, if you aren't a packager you don't have an
> account and can't ssh.

So that would probably be a bug that fedpkg adds remote as [e-mail].o

I started looking at the code but it looks like it got fixed just two
weeks ago:
https://pagure.io/fedpkg/issue/394
https://pagure.io/fedpkg/c/0da2d94

Looks like we just need to wait for an update :)
> > And I think forking your own repo for pull-requests makes perfect sense,
> > especially since distgit doesn't allow you to remove temporary branches
> > from the main repo.
>
> +1

I think there might be a confusion here as well. I was thinking of "your
own repo" as pkgs.fedoraproject.org/forks/yourfaslogin/rpms/repo.git -
which I still don't see much sense in forking, if that is possible at
all.

But now I think everyone is talking about some original repo you're
maintainer of; I have no problem agreeing with that one!

[Miro Hrončok]

On 23. 05. 20 2:19, Aleksandra Fedorova wrote:
> I've got the same problem. I think it uses wrong remote path:
>
> [e-mail]

https://pagure.io/fedpkg/issue/394