Hi, I tried to match what is installed on a system with what is available at git.centos.org.
for example
... [centos-release] $ ../../centos-git-common/show_possible_srpms.sh centos-release-7-0.1406.el7.centos.2.3.src.rpm [centos-release]$ rpm -q centos-release centos-release-7-0.1406.el7.centos.2.4.x86_64 [centos-release]$ rpm -q --qf '%{SOURCERPM}\n' centos-release centos-release-7-0.1406.el7.centos.2.4.src.rpm ...
So centos-release-7-0.1406.el7.centos.2.4.src.rpm is not in git!
Here are all my non matches from quite a minimal system name installed-version latest-in-git
centos-release 7-0.1406.el7.centos.2.4 7-0.1406.el7.centos.2.3 httpd 2.4.6-18.el7.centos 2.4.6-18.el7_0 dhcp 4.2.5-27.el7.centos 4.2.5-27.el7 plymouth 0.8.9-0.10.20140113.el7.centos 0.8.9-0.10.20140113.el7 cronie 1.4.11-11.el7 1.4.11-13.el7 yum 3.4.3-118.el7.centos 3.4.3-118.el7 plymouth 0.8.9-0.10.20140113.el7.centos 0.8.9-0.10.20140113.el7 kexec-tools 2.0.4-32.el7.centos.2 2.0.4-32.el7_0.2 chrony 1.29.1-1.el7.centos 1.29.1-1.el7 basesystem 10.0-7.el7.centos 10.0-7.el7 libreport 2.1.11-10.el7.centos 2.1.11-10.el7 tzdata 2014e-1.el7_0 2014e-1.el7 centos-logos 70.0.6-1.el7.centos 70.0.3-99.el7.centos dhcp 4.2.5-27.el7.centos 4.2.5-27.el7 cronie 1.4.11-11.el7 1.4.11-13.el7 dhcp 4.2.5-27.el7.centos 4.2.5-27.el7 plymouth 0.8.9-0.10.20140113.el7.centos 0.8.9-0.10.20140113.el7
On 08/09/2014 07:14 PM, Markus Falb wrote:
So centos-release-7-0.1406.el7.centos.2.4.src.rpm is not in git!
https://git.centos.org/blob/rpms!centos-release.git/c3f036cce708b37faa1ab667...
it certainly is.
On 10.8.2014 00:11, Karanbir Singh wrote:
On 08/09/2014 07:14 PM, Markus Falb wrote:
So centos-release-7-0.1406.el7.centos.2.4.src.rpm is not in git!
https://git.centos.org/blob/rpms!centos-release.git/c3f036cce708b37faa1ab667...
it certainly is.
Well, it is. show_possible_srpms.sh is broken then, or at least it is not doing what I expected. Is it intended that it only shows redhatishe commits? Is there an easy way to identify the git commit for a CentOS modified src.rpm?
On Sat, Aug 9, 2014 at 7:07 PM, Markus Falb markus.falb@fasel.at wrote:
On 10.8.2014 00:11, Karanbir Singh wrote:
On 08/09/2014 07:14 PM, Markus Falb wrote:
So centos-release-7-0.1406.el7.centos.2.4.src.rpm is not in git!
https://git.centos.org/blob/rpms!centos-release.git/c3f036cce708b37faa1ab667...
it certainly is.
Well, it is. show_possible_srpms.sh is broken then, or at least it is not doing what I expected. Is it intended that it only shows redhatishe commits? Is there an easy way to identify the git commit for a CentOS modified src.rpm?
Fortunately, it looks like a fairly harmless discrepancy. But without that one-to-one mapping between the git log "import" entries, and the SRPM's built, there is always going to be a question of provenance for source code.
This is another reason to want git tags tied to the actual SRPM's, tagged and GPG signed by the procedure that builds SRPM's. It looks like the "make a log entry that starts with the word 'import'" workflow just failed.
On 08/09/2014 01:14 PM, Markus Falb wrote:
Hi, I tried to match what is installed on a system with what is available at git.centos.org.
for example
... [centos-release] $ ../../centos-git-common/show_possible_srpms.sh centos-release-7-0.1406.el7.centos.2.3.src.rpm [centos-release]$ rpm -q centos-release centos-release-7-0.1406.el7.centos.2.4.x86_64 [centos-release]$ rpm -q --qf '%{SOURCERPM}\n' centos-release centos-release-7-0.1406.el7.centos.2.4.src.rpm ...
So centos-release-7-0.1406.el7.centos.2.4.src.rpm is not in git!
Here are all my non matches from quite a minimal system name installed-version latest-in-git
centos-release 7-0.1406.el7.centos.2.4 7-0.1406.el7.centos.2.3 httpd 2.4.6-18.el7.centos 2.4.6-18.el7_0 dhcp 4.2.5-27.el7.centos 4.2.5-27.el7 plymouth 0.8.9-0.10.20140113.el7.centos 0.8.9-0.10.20140113.el7 cronie 1.4.11-11.el7 1.4.11-13.el7 yum 3.4.3-118.el7.centos 3.4.3-118.el7 plymouth 0.8.9-0.10.20140113.el7.centos 0.8.9-0.10.20140113.el7 kexec-tools 2.0.4-32.el7.centos.2 2.0.4-32.el7_0.2 chrony 1.29.1-1.el7.centos 1.29.1-1.el7 basesystem 10.0-7.el7.centos 10.0-7.el7 libreport 2.1.11-10.el7.centos 2.1.11-10.el7 tzdata 2014e-1.el7_0 2014e-1.el7 centos-logos 70.0.6-1.el7.centos 70.0.3-99.el7.centos dhcp 4.2.5-27.el7.centos 4.2.5-27.el7 cronie 1.4.11-11.el7 1.4.11-13.el7 dhcp 4.2.5-27.el7.centos 4.2.5-27.el7 plymouth 0.8.9-0.10.20140113.el7.centos 0.8.9-0.10.20140113.el7
CentOS handles the DIST tag as it always has ... if we make changes, there will be an .el7.centos. If we rebuild the upstream code exactly, then we will use their dist tag exactly. (If this is your question).
Since all DIST tags are dynamic (and the reason for that is because sometimes Red Hat uses .el7 .. sometimes they use .el7_0, .el7_1, etc). Red Hat also does not hard code the DIST tag it is put in at build time as a variable, but not in the SPEC.
So, the dist tag can be whatever you want, it is dynamic, and passed in at the time of build (but not hard coded in the SPEC). That is how Red Hat releases SPECs. If XYZ linux wanted to make every DIST tag be .el7.xyz then they can do that at build time by setting it inside their rpmmacros at build time.
Red Hat used .el7 for packages in their 7.0 QA release, they use .el7_0 for most updates between 7.0 and 7.1 ... but they use .el7 for FasTrac builds. They might, at times, use .el7 for updates (for example, the kernel).
So because of this, we will use dynamic DIST tags.
On Sun, Aug 10, 2014 at 12:08 PM, Johnny Hughes johnny@centos.org wrote:
CentOS handles the DIST tag as it always has ... if we make changes, there will be an .el7.centos. If we rebuild the upstream code exactly, then we will use their dist tag exactly. (If this is your question).
Since all DIST tags are dynamic (and the reason for that is because sometimes Red Hat uses .el7 .. sometimes they use .el7_0, .el7_1, etc). Red Hat also does not hard code the DIST tag it is put in at build time as a variable, but not in the SPEC.
Can you please document that on the Wiki, or point to where it s stated? It may be quite obvious to people who are already steeped in the build system, but I'm afraid the policy has to be deduced, and is thus uncertain, at this point. And it's a question that's come up before.