Hello,
when I download python-slip-dbus-0.2.20-1.el6_2.noarch.rpm from CentOS 6.5 repository the md5sum is different than when I download same file from 6.4.
wget http://msync.centos.org/centos-6/6.5/os/x86_64/Packages/ python-slip-dbus-0.2.20-1.el6_2.noarch.rpm -O python-slip-dbus-0.2.20-1.el6_2.noarch.rpm.65 wget http://msync.centos.org/centos-6/6.4/os/x86_64/Packages/ python-slip-dbus-0.2.20-1.el6_2.noarch.rpm -O python-slip-dbus-0.2.20-1.el6_2.noarch.rpm.64
ls -l ..... 30844 Mar 26 2012 python-slip-dbus-0.2.20-1.el6_2.noarch.rpm.64 ..... 30844 Mar 26 2012 python-slip-dbus-0.2.20-1.el6_2.noarch.rpm.65
md5sum python-slip-dbus-0.2.20-1.el6_2.noarch.rpm.* 20bb02e6f3b7b71e09dcaff7f3b0ca02 python-slip-dbus-0.2.20-1.el6_2.noarch.rpm.64 d37fe4404a7a5fdb27b29f9b5ed09c73 python-slip-dbus-0.2.20-1.el6_2.noarch.rpm.65
Any comments?
Background: We have a local CentOS mirror and after updating to 6.5 the kickstart installation fails because of the wrong md5sum of python-slip-dbus. We mirror with rsync (no -c) and so we had the version from 6.4 in our 6.5 repository.
(Same seams to be true for python-paste-script-1.7.3-5.el6_3.noarch.rpm and slf4j-javadoc-1.5.8-8.el6.noarch.rpm)
Best regards, Ralf
md5sum python-slip-dbus-0.2.20-1.el6_2.noarch.rpm.* 20bb02e6f3b7b71e09dcaff7f3b0ca02 python-slip-dbus-0.2.20-1.el6_2.noarch.rpm.64 d37fe4404a7a5fdb27b29f9b5ed09c73 python-slip-dbus-0.2.20-1.el6_2.noarch.rpm.65
Something got mixed up somewhere. The first one (md5 20bb...) is from the x86_64 branch, both 6.4 and 6.5, and the second one (md5 d37f...) is from the i386 branch, also 6.4 and 6.5.
d37fe4404a7a5fdb27b29f9b5ed09c73 ./6.4/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 20bb02e6f3b7b71e09dcaff7f3b0ca02 ./6.4/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm d37fe4404a7a5fdb27b29f9b5ed09c73 ./6.5/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 20bb02e6f3b7b71e09dcaff7f3b0ca02 ./6.5/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm
On 12/06/2013 12:49 PM, Lars Hecking wrote:
Something got mixed up somewhere. The first one (md5 20bb...) is from the x86_64 branch, both 6.4 and 6.5, and the second one (md5 d37f...) is from the i386 branch, also 6.4 and 6.5.
d37fe4404a7a5fdb27b29f9b5ed09c73 ./6.4/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 20bb02e6f3b7b71e09dcaff7f3b0ca02 ./6.4/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm d37fe4404a7a5fdb27b29f9b5ed09c73 ./6.5/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 20bb02e6f3b7b71e09dcaff7f3b0ca02 ./6.5/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm
Hm, am I the only mirror maintainer that runs hardlinkpy on the tree after each mirror?
Why are there different md5sum's on these files?
They are noarch rpms, so they should be identical in i386 and x86_64?
I get the following:
# md5sum `locate python-slip-dbus-0.2.20-1.el6_2.noarch.rpm` d37fe4404a7a5fdb27b29f9b5ed09c73 /var/ftp/pub/mirrors/centos/6.4/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 20bb02e6f3b7b71e09dcaff7f3b0ca02 /var/ftp/pub/mirrors/centos/6.4/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm d37fe4404a7a5fdb27b29f9b5ed09c73 /var/ftp/pub/mirrors/centos/6.5/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm d37fe4404a7a5fdb27b29f9b5ed09c73 /var/ftp/pub/mirrors/centos/6.5/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm
and: # ls -li `locate python-slip-dbus-0.2.20-1.el6_2.noarch.rpm` 98845547 -rw-rw-r-- 3 mk 500 30844 Mar 26 2012 /var/ftp/pub/mirrors/centos/6.4/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 98315857 -rw-rw-r-- 1 mk 500 30844 Mar 26 2012 /var/ftp/pub/mirrors/centos/6.4/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 98845547 -rw-rw-r-- 3 mk 500 30844 Mar 26 2012 /var/ftp/pub/mirrors/centos/6.5/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 98845547 -rw-rw-r-- 3 mk 500 30844 Mar 26 2012 /var/ftp/pub/mirrors/centos/6.5/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm
Mogens
On 12/07/2013 09:07 AM, Mogens Kjaer wrote:
On 12/06/2013 12:49 PM, Lars Hecking wrote:
Something got mixed up somewhere. The first one (md5 20bb...) is from the x86_64 branch, both 6.4 and 6.5, and the second one (md5 d37f...) is from the i386 branch, also 6.4 and 6.5.
d37fe4404a7a5fdb27b29f9b5ed09c73 ./6.4/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 20bb02e6f3b7b71e09dcaff7f3b0ca02 ./6.4/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm d37fe4404a7a5fdb27b29f9b5ed09c73 ./6.5/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 20bb02e6f3b7b71e09dcaff7f3b0ca02 ./6.5/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm
Hm, am I the only mirror maintainer that runs hardlinkpy on the tree after each mirror?
Why are there different md5sum's on these files?
They are noarch rpms, so they should be identical in i386 and x86_64?
I get the following:
# md5sum `locate python-slip-dbus-0.2.20-1.el6_2.noarch.rpm` d37fe4404a7a5fdb27b29f9b5ed09c73 /var/ftp/pub/mirrors/centos/6.4/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 20bb02e6f3b7b71e09dcaff7f3b0ca02 /var/ftp/pub/mirrors/centos/6.4/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm d37fe4404a7a5fdb27b29f9b5ed09c73 /var/ftp/pub/mirrors/centos/6.5/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm d37fe4404a7a5fdb27b29f9b5ed09c73 /var/ftp/pub/mirrors/centos/6.5/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm
and: # ls -li `locate python-slip-dbus-0.2.20-1.el6_2.noarch.rpm` 98845547 -rw-rw-r-- 3 mk 500 30844 Mar 26 2012 /var/ftp/pub/mirrors/centos/6.4/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 98315857 -rw-rw-r-- 1 mk 500 30844 Mar 26 2012 /var/ftp/pub/mirrors/centos/6.4/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 98845547 -rw-rw-r-- 3 mk 500 30844 Mar 26 2012 /var/ftp/pub/mirrors/centos/6.5/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 98845547 -rw-rw-r-- 3 mk 500 30844 Mar 26 2012 /var/ftp/pub/mirrors/centos/6.5/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm
Mogens
They would not necessarily have the exact same md5sum just because they are noarch. The way mock compiles RPMs, it would be built on each builder separately. The possibility exists that something very minor can (and sometimes does) happen to make things not exact. I will analyze these an tell you the difference in an upcoming e-mail.
We have changed our policy and now we will use the same noarch file, from one of the arches, on both if it exist in the arches. That policy did indeed cause a change in the MD5SUM as they were different before. Again, I'll post in another e-mail what is different between the two, but this is as expected.
It should not happen any more moving forward though, as we will only ever release ONE noarch file in future, regardless of it they built slightly differently from the builders.
Thanks, Johnny Hughes
On 12/09/2013 06:21 AM, Johnny Hughes wrote:
On 12/07/2013 09:07 AM, Mogens Kjaer wrote:
On 12/06/2013 12:49 PM, Lars Hecking wrote:
Something got mixed up somewhere. The first one (md5 20bb...) is from the x86_64 branch, both 6.4 and 6.5, and the second one (md5 d37f...) is from the i386 branch, also 6.4 and 6.5.
d37fe4404a7a5fdb27b29f9b5ed09c73 ./6.4/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 20bb02e6f3b7b71e09dcaff7f3b0ca02 ./6.4/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm d37fe4404a7a5fdb27b29f9b5ed09c73 ./6.5/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 20bb02e6f3b7b71e09dcaff7f3b0ca02 ./6.5/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm
Hm, am I the only mirror maintainer that runs hardlinkpy on the tree after each mirror?
Why are there different md5sum's on these files?
They are noarch rpms, so they should be identical in i386 and x86_64?
I get the following:
# md5sum `locate python-slip-dbus-0.2.20-1.el6_2.noarch.rpm` d37fe4404a7a5fdb27b29f9b5ed09c73 /var/ftp/pub/mirrors/centos/6.4/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 20bb02e6f3b7b71e09dcaff7f3b0ca02 /var/ftp/pub/mirrors/centos/6.4/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm d37fe4404a7a5fdb27b29f9b5ed09c73 /var/ftp/pub/mirrors/centos/6.5/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm d37fe4404a7a5fdb27b29f9b5ed09c73 /var/ftp/pub/mirrors/centos/6.5/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm
and: # ls -li `locate python-slip-dbus-0.2.20-1.el6_2.noarch.rpm` 98845547 -rw-rw-r-- 3 mk 500 30844 Mar 26 2012 /var/ftp/pub/mirrors/centos/6.4/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 98315857 -rw-rw-r-- 1 mk 500 30844 Mar 26 2012 /var/ftp/pub/mirrors/centos/6.4/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 98845547 -rw-rw-r-- 3 mk 500 30844 Mar 26 2012 /var/ftp/pub/mirrors/centos/6.5/os/i386/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 98845547 -rw-rw-r-- 3 mk 500 30844 Mar 26 2012 /var/ftp/pub/mirrors/centos/6.5/os/x86_64/Packages/python-slip-dbus-0.2.20-1.el6_2.noarch.rpm
Mogens
They would not necessarily have the exact same md5sum just because they are noarch. The way mock compiles RPMs, it would be built on each builder separately. The possibility exists that something very minor can (and sometimes does) happen to make things not exact. I will analyze these an tell you the difference in an upcoming e-mail.
We have changed our policy and now we will use the same noarch file, from one of the arches, on both if it exist in the arches. That policy did indeed cause a change in the MD5SUM as they were different before. Again, I'll post in another e-mail what is different between the two, but this is as expected.
It should not happen any more moving forward though, as we will only ever release ONE noarch file in future, regardless of it they built slightly differently from the builders.
OK, the only difference on these RPMs is the signature (it happened at a different time, by one second).
If you look at "rpm -qpi" you will see one of them was signed at:
Signature : RSA/SHA1, Mon 26 Mar 2012 08:36:33 AM CDT, Key ID 0946fca2c105b9de
the other:
Signature : RSA/SHA1, Mon 26 Mar 2012 08:36:32 AM CDT, Key ID 0946fca2c105b9de
(they were 2 separate files, produced in two separate build trees, and therefore have 2 separate signature times)
However, if you do this to each of the files to remove the signatures:
rpm --delsign python-slip-dbus-0.2.20-1.el6_2.noarch.rpm
then do an md5sum, you will see that underlying (and unsigned) rpms have identical md5sums of:
[johnny@m4500n 6.5]$ md5sum python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 8cb0c87fd4942673c79c304d3c29aedb python-slip-dbus-0.2.20-1.el6_2.noarch.rpm
[johnny@m4500n 6.5]$ cd ../6.4/
[johnny@m4500n 6.4]$ md5sum python-slip-dbus-0.2.20-1.el6_2.noarch.rpm 8cb0c87fd4942673c79c304d3c29aedb python-slip-dbus-0.2.20-1.el6_2.noarch.rpm
Also, the content of each RPM is identical at these values:
511a4571af6e42e130c43bfff2507863 ./usr/lib/python2.6/site-packages/slip.dbus-0.2.20-py2.6.egg-info 01bb823d18266732b2cb24d7ea1d693b ./usr/lib/python2.6/site-packages/slip/dbus/__init__.pyc 77ec375c396560fc4dd8bf0160831cfa ./usr/lib/python2.6/site-packages/slip/dbus/bus.pyo 426ba8cb64e3ce60a40042ce961faebc ./usr/lib/python2.6/site-packages/slip/dbus/proxies.pyo 5d5bab55941cb57d18bddb09dc1993bb ./usr/lib/python2.6/site-packages/slip/dbus/proxies.py 01bb823d18266732b2cb24d7ea1d693b ./usr/lib/python2.6/site-packages/slip/dbus/__init__.pyo 89073c18b01d301eefd7169fc08360fa ./usr/lib/python2.6/site-packages/slip/dbus/bus.py dc7e59367bab048fc3bca4fc94e2f5fc ./usr/lib/python2.6/site-packages/slip/dbus/mainloop.pyc 3010ee109154bb35be8458f1e0ab65e1 ./usr/lib/python2.6/site-packages/slip/dbus/polkit.pyo 2af7a635fd80074aa75a095310cbdf96 ./usr/lib/python2.6/site-packages/slip/dbus/polkit.pyc 77ec375c396560fc4dd8bf0160831cfa ./usr/lib/python2.6/site-packages/slip/dbus/bus.pyc dc7e59367bab048fc3bca4fc94e2f5fc ./usr/lib/python2.6/site-packages/slip/dbus/mainloop.pyo 0e2cfc449f2307991ab1c5d1b0839e76 ./usr/lib/python2.6/site-packages/slip/dbus/mainloop.py 635409538835be2bad6e072df6fe50d8 ./usr/lib/python2.6/site-packages/slip/dbus/service.pyo 6d8e78bc35557e342eecce5e7a3b55f1 ./usr/lib/python2.6/site-packages/slip/dbus/polkit.py 3f0ed599e4b44a828d46651e192eaf48 ./usr/lib/python2.6/site-packages/slip/dbus/__init__.py 315ea359d43863330288b57460296bd8 ./usr/lib/python2.6/site-packages/slip/dbus/service.py 9a92a5c97b06379b0d27d40b5835189b ./usr/lib/python2.6/site-packages/slip/dbus/constants.pyc b38049b11f629bb18ec16a529c468c56 ./usr/lib/python2.6/site-packages/slip/dbus/constants.py 9a92a5c97b06379b0d27d40b5835189b ./usr/lib/python2.6/site-packages/slip/dbus/constants.pyo 426ba8cb64e3ce60a40042ce961faebc ./usr/lib/python2.6/site-packages/slip/dbus/proxies.pyc 635409538835be2bad6e072df6fe50d8 ./usr/lib/python2.6/site-packages/slip/dbus/service.pyc 3075a8ae134b28ac0cb602efac73817c ./usr/share/doc/python-slip-dbus-0.2.20/README 031777f09db135ce66c192765c7b1897 ./usr/share/doc/python-slip-dbus-0.2.20/example/org.fedoraproject.slip.example.policy 5518ddb1e0ecc74aaae45e6c10497996 ./usr/share/doc/python-slip-dbus-0.2.20/example/org.fedoraproject.slip.example.mechanism.service b16a87935336095bcbb01fb2ca8265e2 ./usr/share/doc/python-slip-dbus-0.2.20/example/README 8d2b740e128fe5efb7972bcf2cc1343d ./usr/share/doc/python-slip-dbus-0.2.20/example/org.fedoraproject.slip.example.mechanism.conf 00c6cc4ff6554c633144f50860aebd83 ./usr/share/doc/python-slip-dbus-0.2.20/example/example-conf-client.py f4a406243c67d9c357b2c7c1e16e5ec3 ./usr/share/doc/python-slip-dbus-0.2.20/example/Makefile 7f325e65d8a1eb59b8a09bdcb413d6b1 ./usr/share/doc/python-slip-dbus-0.2.20/example/example-conf-mechanism.py d41d8cd98f00b204e9800998ecf8427e ./usr/share/doc/python-slip-dbus-0.2.20/example/import_marker.py
Therefore the only difference is the signatures, and that difference is the time being 1 second different in the rpm metadata ...
We will prevent these in the future because we now ONLY take one of the 2 noarch RPMs and put it in both trees (if applicable to both trees).
Thanks, Johnny Hughes
On 12/09/2013 01:43 PM, Johnny Hughes wrote:
Therefore the only difference is the signatures, and that difference is the time being 1 second different in the rpm metadata ...
A part from the timestamps being different, is it the same key that is used for signing i386 and x86_64 packages?
And why does the OP get an error message?
Is running hardlinkpy on the mirror tree a bad idea in general?
Mogens
On 12/09/2013 07:03 AM, Mogens Kjaer wrote:
On 12/09/2013 01:43 PM, Johnny Hughes wrote:
Therefore the only difference is the signatures, and that difference is the time being 1 second different in the rpm metadata ...
A part from the timestamps being different, is it the same key that is used for signing i386 and x86_64 packages?
And why does the OP get an error message?
Is running hardlinkpy on the mirror tree a bad idea in general?
Mogens
Yes, it is signed by the same key ... but the rpm is not identical. (The difference being a different md5sum because rpm metadata (signature time) is different).
He does not say HOW the installation fails ... one would have to look at the kickstart file to see.
If the ks install is looking at a real 6.5 and pointing at it, it should work fine. If he is pointing at something else, maybe not. I would personally just delete the files in question and rsync again to make sure they are replaced.
Rsync, if it sees the same file and the same date, will not validate the crc without a -c switch ... that would take forever for a whole tree, so I would delete the files in question and sync again from a 6.5 tree.
Hello,
On 12/09/2013 03:16 PM, Johnny Hughes wrote:
Yes, it is signed by the same key ... but the rpm is not identical. (The difference being a different md5sum because rpm metadata (signature time) is different).
He does not say HOW the installation fails ... one would have to look at the kickstart file to see.
anaconda crashes while installing packages. Checking the log-files of the traceback I found something about wrong md5sum of package python-slip-dbus.
If the ks install is looking at a real 6.5 and pointing at it, it should work fine. If he is pointing at something else, maybe not. I would personally just delete the files in question and rsync again to make sure they are replaced.
Rsync, if it sees the same file and the same date, will not validate the crc without a -c switch ... that would take forever for a whole tree, so I would delete the files in question and sync again from a 6.5 tree.
That was the way I fixed the kickstart installation.
Thank You very much for Your explanation of the md5sum difference and best regards,
Ralf
-
Johnny Hughes -
Lars Hecking -
Mogens Kjaer -
Ralf Aumüller