[Application d'un patch] Reversed (or previously applied)

Support Debian
#1

Salut,

Quand je vais sur kernel.org, que je télécharge la version 2.6.32.56 , accompagnée de son patch (2.6.32.56), et que j’essaye de patcher le kernel, j’obtiens ce message sur tous les fichiers :

Reversed (or previously applied) patch detected! Assume -R? [n]

et environ 2 “Hunk Failed”.

Du coup je me demande si je dois vraiment appliquer ce patch, et d’où viendrait le problème ?

J’ai recherché sur google par rapport à ce problème, j’y ai trouvé un peu tout et son contraire.

Merci d’avance pour votre aide.

#2

Si tu télécharges “full-source” de linux-2.6.32.56, tu n’as pas besoin du patch.
Nul besoin de transformer linux-2.6.32.56 en linux-2.6.32.56 .
Ce patch ne sert qu’aux versions antérieures à linux-2.6.32.56

$ man patch

Bugs

      If  you  apply  a  patch  you've  already applied, patch thinks it is a
       reversed patch, and offers to un-apply the patch.  This could  be  con‐
       strued as a feature.

Dépatcher le patch, le contraire du but recherché

[code]
-N or --forward
Ignore patches that seem to be reversed or already applied. See
also -R.
…
-R or --reverse
Assume that this patch was created with the old and new files
swapped. (Yes, I’m afraid that does happen occasionally, human
nature being what it is.) patch attempts to swap each hunk around
before applying it. Rejects come out in the swapped format. The -R
option does not work with ed diff scripts because there is too lit‐
tle information to reconstruct the reverse operation.

      If the first hunk of a patch fails, patch reverses the hunk  to  see
      if it can be applied that way.  If it can, you are asked if you want
      to have the -R option set.  If it can't, the patch continues  to  be
      applied normally.  (Note: this method cannot detect a reversed patch
      if it is a normal diff and if the first command is an  append  (i.e.
      it  should  have been a delete) since appends always succeed, due to
      the fact that  a  null  context  matches  anywhere.   Luckily,  most
      patches  add  or  change  lines  rather  than  delete  them, so most
      reversed normal diffs begin with a delete, which  fails,  triggering
      the heuristic.)[/code]
#3

patch-2.6.32.56 contient toutes les modifications entre linux-2.6.32 et linux-2.6.32.56.
Il te servira quand tu voudras par exemple passer à une version ultérieure sans retélécharger les sources en entier :

  • application à rebours de patch-2.6.32.56 pour revenir en 2.6.32
  • application de patch-2.6.32.57 pour arriver en 2.6.32.57

On peut aussi appliquer directement le patch incrémental patch-2.6.32.56-57 sur les sources 2.6.32.56, mais si on saute des versions il faut appliquer tous les patches incrémentaux intermédiaires.

#4

Merci pour la confirmation.

Au début ça m’avait semblé bizarre aussi de devoir patcher une version X avec un patch X, et c’est pour ça que je suis venu demander ce qui clochait ici. J’ai suivis un tuto de compilation de kernel 1000hz dont j’ai perdu le lien, qui disait qu’il était impératif de télécharger les deux en même temps (ça semble idiot vu qu’ils portent la même version, et que toute modification en entraînerait le changement).

Et j’ai trouvé la raison de ces conseils peu avisés : le tuto était la traduction (approximative) d’un autre tuto anglais.

#5

Cette recommandation n’est pas idiote. Je la suis moi-même pour la raison que j’ai indiquée : pouvoir ultérieurement patcher les sources pour passer à une autre version sans devoir tout télécharger à nouveau.