On Tue, 14 Feb 2017, Steven Rostedt wrote: > On Tue, 14 Feb 2017 19:42:35 +0100 > Dominic Sacré wrote: > > > Could this be the cause of your issue? > > > > I think so. Looking at the current contents of rt/4.1, I see that > > patch-4.1.38-rt45.patch.gz and older/patch-4.1.38-rt45.patch.gz have > > different sha256 hashes. I would have expected them to be copies of the > > exact same file, so I guess the question is why they're different in the > > first place. > > It's the way kernel.org does the updates. I upload a .xz file and a > signed gpg file of the uncompressed image. kernel.org creates the gz > file from the uncompressed version. As I upload it twice, kernel.org > does two gzips of the uncompressed file. I'm guessing that there's a > timestamp that gets used as well, making both gzipped files different, > even though what they contain are the same. Right. And it does not matter at all. The sha256 tells you that the file you downloaded is the one which kernel.org advertised to you. Not more, not less. The content is protected by the *.patch.sign and *.tar.sign files. > I may need to change my workflow to simply delete the file in the > current directory than to move it. And the point is? > Although, I had better make sure that there's a copy in the older > directory first. Maybe I'll change my tool to download the older and > current versions, uncompress them, make sure they are the same, and if > they are, remove the current version, else, move the current version on > the older one. That does not make any sense. The proper thing to do is move file from rt/4.x/ to rt/4.x/older. If kernel.org decides to redo the archives, then you can't do anything about it. And if you upload it another time there is no guarantee either that the resulting gz/xz are the same. What matters is the content and not the compressed thingy. Again: - The sha256 only tells you that the download was not corrupted. - The PGP signature is what protects the content and that does not change whether you move it or upload the same thing again. Thanks, tglx