On Fri, Mar 10, 2017 at 06:19:47PM -0500, Steven Rostedt wrote: > On Sat, 11 Mar 2017 00:13:25 +0100 > Dominic Sacré <dominic.sacre@xxxxxx> wrote: > > > Hi all, > > > > I'm sorry to bring this up again, but it looks like > > 4.1/older/patch-4.1.38-rt45.patch.gz changed when -rt46 was released, so > > the Bitbake recipes that use this patch are now broken again. > > Note, Julia just took over for 4.1-rt maintainership, so there is going > to be some expected hiccups along the way until she is fully up to > speed. Please have patience during this time. *sigh*. I was setup to fail here, wasn't I? :). I even recalled this thread, but thought "surely if I do the most obvious thing, I won't run into problems!". [..] > > IMHO it's bad practice for files to change once they've been released > > (with a version number and everything), even if the contents remain the > > same. The sha256-based approach seems to be working for thousands of > > projects in OpenEmbedded; I don't see any particular reason for patches > > on kernel.org to be any different. > > > > By the way, the 4.1.38-rt46 release is currently still missing from the > > "older" directory. > > Julia, > > Just an FYI, especially if you are using my older scripts (I haven't > updated the ones I posted). I was asked when I do my upload of a new > version to copy to both the main and older directory. But my scripts > still moved the main to the older one when a new release went out. This > caused the checksums of the created .gz to change in the older > directory. > > What I do now is to still upload to both main and older, but when I > have a new release, I simply delete the main one, as the older one > already exists. Okay, sounds simple enough. I've uploaded both the patch and series tarball to older/, which should now remain unchanged. I'd still like to understand why kernel.org decides to re-compress when the simply moving patches around... Thanks, Julia -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
