-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFE: Automated exportpatches tool, reverse of importpatches #17
Comments
As for deployment, a MVP will require running the script from dist-git. Later we can iterate on top of that by fetching the latest builds from Koji daily or even responding to Koji builds by consuming some fedora-message kind of things, but that's out of scope here. |
If I manually git am existing patches we have on python3.11, I end up with different hashes. When I then imortpatches them back, this is the difference: diff --git a/python3.11.spec b/python3.11.spec
index d8003bc..06da5d4 100644
--- a/python3.11.spec
+++ b/python3.11.spec
@@ -263,8 +263,7 @@ Source11: idle3.appdata.xml
# (Patches taken from github.com/fedora-python/cpython)
# 00001 # d06a8853cf4bae9e115f45e1d531d2dc152c5cc8
-# Fixup distutils/unixccompiler.py to remove standard library path from rpath
-# Was Patch0 in ivazquez' python3000 specfile
+# Fixup distutils/unixccompiler.py to remove standard library path from rpath Was Patch0 in ivazquez' python3000 specfile
Patch1: 00001-rpath.patch
# 00251 # 531494a5ded29dad59f617304dab4eb8b7f80b0b Apparently, patch 1 has an inconsistency between the commit message in spec and in the patch. I wonder how is that possible. When I manually format-patch it, the newline is gone. Heh :D |
Oh, alrighty, when adding For the record, the subject of patch 1 changes this way: -Subject: [PATCH] 00001: Fixup distutils/unixccompiler.py to remove standard
- library path from rpath Was Patch0 in ivazquez' python3000 specfile
+Subject: =?UTF-8?q?00001:=20Fixup=20distutils/unixccompiler.py=20to=20remo?=
+ =?UTF-8?q?ve=20standard=20library=20path=20from=20rpath=0AWas=20Patch0=20?=
+ =?UTF-8?q?in=20ivazquez'=20python3000=20specfile?= I think that we can afford amending this commit message once, some to get rid of the weridness. OTOH if we are to do this, we should probably use |
I'd like to be able to construct the content of a git branch from dist-git. If done nicely, we can automate creating tags in https://github.com/fedora-python/cpython whenever Koji build happens - that way we could stop caring about the tags and branch content manually and the entire workflow would be much simplicifed.
My idea for
exportpatches
is that it will:git reset --hard
to the appropriate @python/cpythonv%{version}
git taggit am
the patches from the spec file, one by one, ideally using--committer-date-is-author-date
for a reproducible commit hash -- he commit messages are included in the patches, so we don't parse them from the specfile comments -- we only use the spec to get the list of patch filesfedora-%{version}-%{release}
tag (release might as well contain the dist tag, so we can apply this behavior to diverged patches, like 251) and push it to @fedora-python/cpython (if enabled)git reset --hard
thefedora-%{version}
to what we have just created and push force that one (if enabled)I'd like to have this reproducible. When a new patch is added on top, we want a new commit on top, not an entirely fresh set of commits. I believe
--committer-date-is-author-date
should make that happen, but will see. Also when run from different machines, the commit hashes should remain identical.The text was updated successfully, but these errors were encountered: