2:29 a.m.
Hi! :)
One of the package review guideline says
===
MUST: The sources used to build the package must match the
upstream source, as provided in the spec URL. Reviewers should use
md5sum for this task.
===
Past couple of days, I've been reviewing the python grapefruit package
at - https://bugzilla.redhat.com/show_bug.cgi?id=716808
and the thing is, the spec file provides an - $ svn export -r 31 ... - command to pull the
sources and create a tarball using $ tar -czvf ...
But as it turns out, it seems, if you create a tarball from the *very same* sources on two
different machines, they don't match. As in the md5sum for the two tarball differs.
Please try this simple test
=====
$ echo 'Hello, world' > 1
$ tar -cjf 1.tar.bz2 1
$ scp 1.tar.bz2 to a different machine.
$ ssh to that same machine
$ tar -xjf 1.tar.bz2 -C .
$ tar -cjf 2.tar.bz2 1
$ md5sum 1.tar.bz2 2.tar.bz2
d67ea3dac09ed7eee310d9846ecdd879 1.tar.bz2
d4b716716f3cf48139c4112719538513 2.tar.bz2
=====
Could someone suggest how to fix this glitch? Or the guideline above??
Thank you.
---
Regards
-Prasad
http://feedmug.com
2:48 a.m.
On Wed, 29 Jun 2011 12:59:41 +0530 (IST), PJP (P) wrote:
One of the package review guideline says
===
MUST: The sources used to build the package must match the
upstream source, as provided in the spec URL. Reviewers should use
md5sum for this task.
===
It says more than that:
| If no upstream URL can be specified for this package, please see the
| Source URL Guidelines for how to deal with this.
-> https://fedoraproject.org/wiki/Packaging/SourceURL
-> https://fedoraproject.org/wiki/Packaging/SourceURL#Using_Revision_Control
That is the guideline that's releveant.
Past couple of days, I've been reviewing the python grapefruit
package
at - https://bugzilla.redhat.com/show_bug.cgi?id=716808
and the thing is, the spec file provides an - $ svn export -r 31 ... - command to pull
the sources and create a tarball using $ tar -czvf ...
But as it turns out, it seems, if you create a tarball from the *very same* sources on
two different machines, they don't match. As in the md5sum for the two tarball
differs.
Examine whether the uncompressed tarball differs already due to file
timestamps or file system differences. A simple md5sum isn't helpful in
that case. You would verify an svn snapshot tarball with a full tree diff,
possibly deleting the revision control maintenance directories beforehand.
3:24 a.m.
P J P <pj.pandit(a)yahoo.co.in> writes:
But as it turns out, it seems, if you create a tarball from the *very
same* sources on two different machines, they don't match. As in the md5sum for the
two tarball differs.
Make sure to disable the gzip timestamp.
Andreas.
--
Andreas Schwab, schwab(a)redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
5:11 a.m.
----- Original Message -----
From: Andreas Schwab <schwab(a)redhat.com>
Make sure to disable the gzip timestamp.
...how do you do that?
I tried using - $ tar --atime-preserve - etc. but didn't help.
Thanks.
---
Regards
-Prasad
http://feedmug.com
6:07 a.m.
P J P <pj.pandit(a)yahoo.co.in> writes:
----- Original Message -----
> From: Andreas Schwab <schwab(a)redhat.com>
> Make sure to disable the gzip timestamp.
...how do you do that?
$ gzip --help
-n, --no-name do not save or restore the original name and time stamp
Andreas.
--
Andreas Schwab, schwab(a)redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
6:26 a.m.
On Wed, Jun 29, 2011 at 6:07 AM, Andreas Schwab <schwab(a)redhat.com> wrote:
P J P <pj.pandit(a)yahoo.co.in> writes:
> ----- Original Message -----
>> From: Andreas Schwab <schwab(a)redhat.com>
>> Make sure to disable the gzip timestamp.
>
>
> ...how do you do that?
$ gzip --help
-n, --no-name do not save or restore the original name and time stamp
The -j in "tar -cjf" means to compress using bzip2, so I don't think gzip
is
used, at least in his example.
Andreas.
--
Andreas Schwab, schwab(a)redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Aaron Faanes <dafrito(a)gmail.com>
7:37 a.m.
________________________________
From: Aaron Faanes <dafrito(a)gmail.com>
>$ gzip --help
> -n, --no-name do not save or restore the original name and time stamp
The -j in "tar -cjf" means to compress using bzip2, so I don't think gzip is
used, at least in his example.
Yep, gzip or even other compressions are are not used separately; but via tar(1).
---
Regards
-Prasad
http://feedmug.com
6:42 a.m.
On Wed, Jun 29, 2011 at 2:29 AM, P J P <pj.pandit(a)yahoo.co.in> wrote:
Hi! :)
One of the package review guideline says
===
MUST: The sources used to build the package must match the
upstream source, as provided in the spec URL. Reviewers should use
md5sum for this task.
===
Past couple of days, I've been reviewing the python grapefruit package
at - https://bugzilla.redhat.com/show_bug.cgi?id=716808
and the thing is, the spec file provides an - $ svn export -r 31 ... -
command to pull the sources and create a tarball using $ tar -czvf ...
But as it turns out, it seems, if you create a tarball from the *very same*
sources on two different machines, they don't match. As in the md5sum for
the two tarball differs.
Please try this simple test
=====
$ echo 'Hello, world' > 1
$ tar -cjf 1.tar.bz2 1
$ scp 1.tar.bz2 to a different machine.
$ ssh to that same machine
$ tar -xjf 1.tar.bz2 -C .
$ tar -cjf 2.tar.bz2 1
$ md5sum 1.tar.bz2 2.tar.bz2
d67ea3dac09ed7eee310d9846ecdd879 1.tar.bz2
d4b716716f3cf48139c4112719538513 2.tar.bz2
=====
Could someone suggest how to fix this glitch? Or the guideline above??
I ran your example, but I got the expected results:
$ echo 'Hello, world' > 1
$ tar -cjf 1.tar.bz2 1
$ scp 1.tar.bz2 $HOST:~
1.tar.bz2 100%
130 0.1KB/s 00:00
$ ssh $HOST
Last login: Fri Jun 3 21:38:56 2011 from ...
$ tar -xjf 1.tar.bz2 -C .
$ tar -cjf 2.tar.bz2 1
$ md5sum 1.tar.bz2 2.tar.bz2
b87d0f263bfec97456a415f7103b0f35 1.tar.bz2
b87d0f263bfec97456a415f7103b0f35 2.tar.bz2
My guess is that the ssh'd host uses a different username/group or uses a
different filesystem. You could compare the two using rsync:
$ mkdir 1.dir 2.dir
$ ls
1.dir 1.tar.bz2 2.dir 2.tar.bz2
$ tar -xjf 1.tar.bz2 -C 1.dir
$ tar -xjf 2.tar.bz2 -C 2.dir
$ rsync -avznih 1.dir/ 2.dir/
sending incremental file list
.d..t...... ./
sent 62 bytes received 15 bytes 154.00 bytes/sec
total size is 13 speedup is 0.17 (DRY RUN)
If the files differ, it should show up in rsync's itemized changes, like the
following example:
$ su -c 'chown root:root 2.dir/1'
Password:
$ rsync -avznih 1.dir/ 2.dir/
sending incremental file list
.d..t...... ./
.f.....g... 1
sent 65 bytes received 18 bytes 166.00 bytes/sec
total size is 13 speedup is 0.16 (DRY RUN)
Thank you.
---
Regards
-Prasad
http://feedmug.com
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Hope this helps!
- Aaron
8:26 a.m.
________________________________
From: Aaron Faanes <dafrito(a)gmail.com>
My guess is that the ssh'd host uses a different username/group or uses a
different filesystem. You could compare the two using rsync:
Hmmn..strange. Nope, username/group are same, even the file system(ext4) is same. I
checked it on 3-4(F11, F14, RHEL6) different machines, everywhere it was different.
If the files differ, it should show up in rsync's itemized
changes, like the
following example:
Will check this rsync(1) test, should work.
Thanks.
---
Regards
-Prasad
http://feedmug.com
4678
days inactive
4678
days old
8 comments
4 participants
participants (4)
-
Aaron Faanes -
Andreas Schwab -
Michael Schwendt -
P J P