hi,
There still seems to be some level of ambiguity as to how we are doing the change requests, rebuild requests and change requests so I wanted to get a short summary on the list and we can pickup details where needed.
For anything that anyone sees that needs a change : file an issue report at bugs.centos.org; this is most important. Then see if you can also propose a patch.
In order to propose a patch you need to run through a few steps( in this example assuming we want to patch httpd ):
$ git clone https://git.centos.org/git/centos-git-common.git $ git clone https://git.centos.org/git/rpms/httpd.git $ cd httpd $ git branch -a $ git checkout c7 $ bash ../centos-git-common/get_sources.sh $ git rev-parse HEAD > `whoami`.start-point $ bash ../centos-git-common/rpm-tree-prep.sh
At this point you should be good to make changes to SPECS/ SOURCES/ and BUILD/package-name ( note that the rpm-tree-prep.sh script will setup a __orig dir for you to build patches against.
once you have the content ready, git commit the changes, in multiple commits, to have a complete, but as small as possible, change in one commit. Eg. if you are fixing 5 things, ideally end up with 5 commits. Also, if you are adding content, to replace something else that is going away, make sure you have the delete and addition in the same commit. Eg. replacing xulrunner-redhat-prefs.js with xulrunner-centos-prefs.js - add the git rm and git add into the same commit.
Once you are happy with the state of play, go back to the root of the git repo, and :
$ git format-patch $(cat `whoami`.start-point)
this will leave behind files, one per commit that you made, in the format : NNNN-<commit summary>.patch : these are the files you need to attach to bugs.centos.org; these files contain your user metadata as well, and can then be applied as is. So you get credit for the changes, and we are able to replay exactly the change you had in mind.
NOTES:
CentOS patches added to the SPEC file should be named : <packagename>-CentOS-<change being made>.patch
When added to the spec file, its a good practise to skip a few hundred spots on the patch list. Eg. if the spec has no patches, then start the CentOS patches at Patch1000 onward. If the spec already has patches, then skip a large number. This is just so we dont have ( or are less likely to have ) Patch number conflict with upstream changes in the life of CentOS-7
lets get patching, todays build is definitely on.
Should we post this on the wiki somewhere?
Carl.
On 06/17/2014 07:45 AM, Karanbir Singh wrote:
hi,
There still seems to be some level of ambiguity as to how we are doing the change requests, rebuild requests and change requests so I wanted to get a short summary on the list and we can pickup details where needed.
For anything that anyone sees that needs a change : file an issue report at bugs.centos.org; this is most important. Then see if you can also propose a patch.
In order to propose a patch you need to run through a few steps( in this example assuming we want to patch httpd ):
$ git clone https://git.centos.org/git/centos-git-common.git $ git clone https://git.centos.org/git/rpms/httpd.git $ cd httpd $ git branch -a $ git checkout c7 $ bash ../centos-git-common/get_sources.sh $ git rev-parse HEAD > `whoami`.start-point $ bash ../centos-git-common/rpm-tree-prep.sh
At this point you should be good to make changes to SPECS/ SOURCES/ and BUILD/package-name ( note that the rpm-tree-prep.sh script will setup a __orig dir for you to build patches against.
once you have the content ready, git commit the changes, in multiple commits, to have a complete, but as small as possible, change in one commit. Eg. if you are fixing 5 things, ideally end up with 5 commits. Also, if you are adding content, to replace something else that is going away, make sure you have the delete and addition in the same commit. Eg. replacing xulrunner-redhat-prefs.js with xulrunner-centos-prefs.js - add the git rm and git add into the same commit.
Once you are happy with the state of play, go back to the root of the git repo, and :
$ git format-patch $(cat `whoami`.start-point)
this will leave behind files, one per commit that you made, in the format : NNNN-<commit summary>.patch : these are the files you need to attach to bugs.centos.org; these files contain your user metadata as well, and can then be applied as is. So you get credit for the changes, and we are able to replay exactly the change you had in mind.
NOTES:
CentOS patches added to the SPEC file should be named : <packagename>-CentOS-<change being made>.patch
When added to the spec file, its a good practise to skip a few hundred spots on the patch list. Eg. if the spec has no patches, then start the CentOS patches at Patch1000 onward. If the spec already has patches, then skip a large number. This is just so we dont have ( or are less likely to have ) Patch number conflict with upstream changes in the life of CentOS-7
lets get patching, todays build is definitely on.
On 06/17/2014 05:42 PM, Carl Trieloff wrote:
Should we post this on the wiki somewhere?
Carl.
+1
On 06/17/2014 07:45 AM, Karanbir Singh wrote:
hi,
There still seems to be some level of ambiguity as to how we are doing the change requests, rebuild requests and change requests so I wanted to get a short summary on the list and we can pickup details where needed.
For anything that anyone sees that needs a change : file an issue report at bugs.centos.org; this is most important. Then see if you can also propose a patch.
In order to propose a patch you need to run through a few steps( in this example assuming we want to patch httpd ):
$ git clone https://git.centos.org/git/centos-git-common.git $ git clone https://git.centos.org/git/rpms/httpd.git $ cd httpd $ git branch -a $ git checkout c7 $ bash ../centos-git-common/get_sources.sh $ git rev-parse HEAD > `whoami`.start-point $ bash ../centos-git-common/rpm-tree-prep.sh
At this point you should be good to make changes to SPECS/ SOURCES/ and BUILD/package-name ( note that the rpm-tree-prep.sh script will setup a __orig dir for you to build patches against.
once you have the content ready, git commit the changes, in multiple commits, to have a complete, but as small as possible, change in one commit. Eg. if you are fixing 5 things, ideally end up with 5 commits. Also, if you are adding content, to replace something else that is going away, make sure you have the delete and addition in the same commit. Eg. replacing xulrunner-redhat-prefs.js with xulrunner-centos-prefs.js - add the git rm and git add into the same commit.
Once you are happy with the state of play, go back to the root of the git repo, and :
$ git format-patch $(cat `whoami`.start-point)
this will leave behind files, one per commit that you made, in the format : NNNN-<commit summary>.patch : these are the files you need to attach to bugs.centos.org; these files contain your user metadata as well, and can then be applied as is. So you get credit for the changes, and we are able to replay exactly the change you had in mind.
NOTES:
CentOS patches added to the SPEC file should be named : <packagename>-CentOS-<change being made>.patch
When added to the spec file, its a good practise to skip a few hundred spots on the patch list. Eg. if the spec has no patches, then start the CentOS patches at Patch1000 onward. If the spec already has patches, then skip a large number. This is just so we dont have ( or are less likely to have ) Patch number conflict with upstream changes in the life of CentOS-7
lets get patching, todays build is definitely on.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 06/17/2014 01:12 PM, Carl Trieloff wrote:
Should we post this on the wiki somewhere?
We might need to iterate over this a few times till we have something finalised - will put it linked from wiki.centos.org/sources after that.
I'm also writing something similar for people doing the merge/ack/commit into git.centos.org
- KB
On 06/17/2014 07:26 AM, Karanbir Singh wrote:
On 06/17/2014 01:12 PM, Carl Trieloff wrote:
Should we post this on the wiki somewhere?
We might need to iterate over this a few times till we have something finalised - will put it linked from wiki.centos.org/sources after that.
I'm also writing something similar for people doing the merge/ack/commit into git.centos.org
- KB
I wouldn't mind seeing the final version in the README.md file of centos-git-common.
Pat
On 2014-06-17 13:45, Karanbir Singh wrote:
$ git clone https://git.centos.org/git/centos-git-common.git $ git clone https://git.centos.org/git/rpms/httpd.git $ cd httpd $ git branch -a
Why would listing branches be necessary?
$ git checkout c7
<snip>
$ git rev-parse HEAD > `whoami`.start-point
<snip>
$ git format-patch $(cat `whoami`.start-point)
These could be replace with `git format-patch origin/c7` (or `git format-patch "@{upstream}"`).
On 06/17/2014 02:46 PM, Elias Persson wrote:
On 2014-06-17 13:45, Karanbir Singh wrote:
$ git clone https://git.centos.org/git/centos-git-common.git $ git clone https://git.centos.org/git/rpms/httpd.git $ cd httpd $ git branch -a
Why would listing branches be necessary?
mostly as a FYI, some repos dont have a c7 tree, ofcourse people are likely not trying to submit patches for those either...
$ git checkout c7
<snip>
$ git rev-parse HEAD > `whoami`.start-point
<snip> > $ git format-patch $(cat `whoami`.start-point) >
These could be replace with `git format-patch origin/c7` (or `git format-patch "@{upstream}"`).
if that is where one starts from, internally we pass git repos around so we dont always need to start from HEAD. I would assume that as people get friendlier with this, they will just git branch my-branch etc and not do edits in the c7/ branch ( given that they cant push back to c7 anyway ).
please, submit patches that make this process easier as a getting-started guide.
On 06/17/2014 12:45 PM, Karanbir Singh wrote:
$ bash ../centos-git-common/rpm-tree-prep.sh
i suspect this is going to be replaced with the far more elegant centpkg at some point, but for now it works, as a hack and a half.
-
Carl Trieloff -
Elias Persson -
Karanbir Singh -
Lalatendu Mohanty -
Pat Riehecky