New_Package_Process_for_Existing_Contributors needs to be updated to include non `fedpkg import` method

ankursinha commented

2022-01-05 18:40:59 +00:00

Member

when folks use rpmautospec, they can no longer use fedpkg import because the SRPM has the expanded form of the rpmautospec macros. Using fedpkg import also throws away the git history. So, we need to document how to import a package without using fedpkg import.

See this thread for more info:

https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/message/YEU4U72X6PWZWWNTPF755W5JIQ3IVHXH/

Steps (need to be verified):

add the SCM as new remote: git remote add origin ...
fetch it: git fetch origin
set it as the remote: git branch main -t origin/main
rebase the branch on top of the SCM's branch: git rebase origin/main

I think this has other caveats though:

one has to run fedpkg new-sources manually to upload the sources to the lookaside cache
one has to make sure no other files are in the repo now (sometimes folks include the srpm there during review etc.)

CC: @vondruch @churchyard

when folks use rpmautospec, they can no longer use `fedpkg import` because the SRPM has the expanded form of the rpmautospec macros. Using `fedpkg import` also throws away the git history. So, we need to document how to import a package without using `fedpkg import`. See this thread for more info: https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/message/YEU4U72X6PWZWWNTPF755W5JIQ3IVHXH/ Steps (need to be verified): - add the SCM as new remote: `git remote add origin ...` - fetch it: `git fetch origin` - set it as the remote: `git branch main -t origin/main` - rebase the branch on top of the SCM's branch: `git rebase origin/main` I think this has other caveats though: - one has to run `fedpkg new-sources` manually to upload the sources to the lookaside cache - one has to make sure no other files are in the repo now (sometimes folks include the srpm there during review etc.) CC: @vondruch @churchyard

vondruch commented

2022-01-06 09:51:44 +00:00

Member

This would probably deserve its own page, because:

This is common issue for New_Package_Process_for_New_Contributors.adoc as well as for New_Package_Process_for_Existing_Contributors.adoc, so both could refer to this workflow.
This is IMO very similar situation to git init local repository you'd like to push later into GH created repo.
The New_Package_Process_for_Existing_Contributors.adoc would deserve overhaul on its own. It is interesting that this page contains paragraphs such as "** If you have already got a Fedora Account then you can use your storage at http://fedorapeople.org for this." while this would probably belong to the New_Package_Process_for_New_Contributors.adoc.

However, part of this are pure git tricks, while the others are fedora specific tricks, not sure how combine these ...

This would probably deserve its own page, because: 1. This is common issue for New_Package_Process_for_New_Contributors.adoc as well as for New_Package_Process_for_Existing_Contributors.adoc, so both could refer to this workflow. 2. This is IMO very similar situation to `git init` local repository you'd like to push later into GH created repo. 3. The New_Package_Process_for_Existing_Contributors.adoc would deserve overhaul on its own. It is interesting that this page contains paragraphs such as "** If you have already got a Fedora Account then you can use your storage at http://fedorapeople.org for this." while this would probably belong to the New_Package_Process_for_New_Contributors.adoc. However, part of this are pure git tricks, while the others are fedora specific tricks, not sure how combine these ...

vondruch commented

2022-01-06 09:53:31 +00:00

Member

Wouldn't be better to teach fedpkg to rebase the local repository and make from it the dist-git repo? That would save us from the need to describe this ;)

vondruch commented

2022-01-06 09:59:21 +00:00

Member

Wouldn't be better to teach fedpkg to rebase the local repository and make from it the dist-git repo? That would save us from the need to describe this ;)

And BTW, part of the issue might be already resolved actually:

https://pagure.io/rpkg/pull-request/560

I have just never found the cycles to try the final implementation 🙈

> Wouldn't be better to teach fedpkg to rebase the local repository and make from it the dist-git repo? That would save us from the need to describe this ;) And BTW, part of the issue might be already resolved actually: https://pagure.io/rpkg/pull-request/560 I have just never found the cycles to try the final implementation :see_no_evil:

vondruch commented

2022-01-06 12:12:22 +00:00

Member

Wouldn't be better to teach fedpkg to rebase the local repository and make from it the dist-git repo? That would save us from the need to describe this ;)

And BTW, part of the issue might be already resolved actually:

https://pagure.io/rpkg/pull-request/560

I have just never found the cycles to try the final implementation 🙈

So this works:

$ fedpkg remote add --remote-name origin --repo-name my-new-package

However, it adds just anonymous URL :/

> > Wouldn't be better to teach fedpkg to rebase the local repository and make from it the dist-git repo? That would save us from the need to describe this ;) > > And BTW, part of the issue might be already resolved actually: > > https://pagure.io/rpkg/pull-request/560 > > I have just never found the cycles to try the final implementation :see_no_evil: So this works: ~~~ $ fedpkg remote add --remote-name origin --repo-name my-new-package ~~~ However, it adds just anonymous URL :/

vondruch commented

2022-01-06 13:05:10 +00:00

Member

However, it adds just anonymous URL :/

Request of non-anonymous URL is here:

https://pagure.io/rpkg/issue/599

> However, it adds just anonymous URL :/ Request of non-anonymous URL is here: https://pagure.io/rpkg/issue/599

ankursinha commented

2022-01-07 18:17:46 +00:00

Author

Member

Yeh, it'll be good if we can teach fedpkg all of this, otherwise it can be quite a complex process, especially for newcomers who are meant to benefit from fedpkg usage. I had to write this all up for our Outreachy intern:

https://pagure.io/neuro-sig/NeuroFedora/issue/496#comment-773460

Now, they had committed other files to the SCM etc, so there were extra steps to get things done. It's really not a simple process at all. I'm now wondering if I should've asked them to use fedpkg import and then correct the spec instead---we'd lose git history, but it'd be wayy easier!

Yeh, it'll be good if we can teach `fedpkg` all of this, otherwise it can be quite a complex process, especially for newcomers who are meant to benefit from fedpkg usage. I had to write this all up for our Outreachy intern: https://pagure.io/neuro-sig/NeuroFedora/issue/496#comment-773460 Now, they had committed other files to the SCM etc, so there were extra steps to get things done. It's really not a simple process at all. I'm now wondering if I should've asked them to use `fedpkg import` and then correct the spec instead---we'd lose git history, but it'd be wayy easier!

vondruch commented

2023-11-29 08:40:08 +00:00

Member

However, it adds just anonymous URL :/

Request of non-anonymous URL is here:

https://pagure.io/rpkg/issue/599

This has been resolved upstream. Not sure when it lands in Fedora though.

> > However, it adds just anonymous URL :/ > > Request of non-anonymous URL is here: > > https://pagure.io/rpkg/issue/599 This has been resolved upstream. Not sure when it lands in Fedora though.

Rows
Columns

New_Package_Process_for_Existing_Contributors needs to be updated to include non fedpkg import method #52

New_Package_Process_for_Existing_Contributors needs to be updated to include non `fedpkg import` method #52