Hello, Mark, Apologies for the delay in responding. It's been an "interesting" week.
I'm breaking up what turned out to be a very very long reply into multiple posts, so as to address the various issues in separate posts, that might very well turn into separate subthreads. On Aug 15, 2020, Mark H Weaver <m...@netris.org> wrote: > Alexandre Oliva <lxol...@fsfla.org> wrote: >> No. There are much better (faster and less risky) ways to tend to that >> requirement, see #bisecting below. > [...] >> #bisecting >> >> You can even take one of our releases and apply the patches that went >> into the next upstream stable release, and check that what you get >> matches our own corresponding release. Some 98% of the time, they will >> be exact matches. Occasionally, there will be a difference, and then >> you'll likely find a corresponding change in the deblobbing scripts, or >> a preexisting pattern that caused the change. We do this for every >> release, as part of our pre-release checks, and you're welcome to do so >> as well, and to use the resulting tree to bisect problems. > I agree that this would be faster, but I fail to see how it's "less > risky" than running the deblob scripts meant for Linux-libre X.Y.Z on a > git checkout of the upstream stable git repo between X.Y.(Z-1) and > X.Y.Z. You're right. My mistake was failing to mention the need to compare between X.Y.Z-gnu* and the result of rebasing the X.Y.(Z-1)..X.Y.Z patches onto X.Y.(Z-1)-gnu* to enjoy the safety I had in mind. If the changes made to both ends are the same, then it's not entirely unreasonable to assume that all intermediate commits would also be properly cleaned up with the same set of changes, assuming the history in between is linear (i.e., only cherry-picks, not merges that could take a bisect to much earlier commits). Even with linear history, you might admittedly still be surprised if an intervening patch introduces something undesirable and a subsequent one reverses it. Running through deblob-check each version of each modified file that matches neither boundary would mechanically avoid nearly all such surprises. > More importantly, it's a much less straightforward thing to implement. It really isn't. Once you remove the deblobbing and point the recipe directly at the linux-libre git repo, users will be able to do the above rebasing on a local repo, and build reasonably quickly any of the commits that the local git bisect tells them to try. > In the current implementation, we get the ability to deblob arbitrary > git commits from the same stable branch essentially for free. Taking arbitrary commits from a known non-Free repo is really not something to be encouraged, given the odds of hitting freedom problems. When using the latest scripts for a stable series, odds are the procedure you suggest would work more or less reliably within that stable series, but we've recently had an example in the 5.7-gnu series in which it wouldn't. > I guess you're suggesting that I should implement a radically different > mechanism specifically for this purpose, that extracts the individual > patches from the upstream stable git repository, attempt to apply them > to the base Linux-libre release, compare that to the next Linux-libre > release, and then implement my own bisection functionality. git rebase --onto libre/vX.Y.(Z-1)-gnu nonfree/vX.Y.(Z-1) nonfree/vX.Y.Z git diff libre/vX.Y.Z-gnu git bisect start HEAD libre/vX.Y.(Z-1)-gnu > If I were to implement this, what would you suggest I do if the patches > fail to apply Look at the conflict presented by the rebase, and resolve the likely freedom issue introduced at that point. > if the result fails to match the next Linux-libre release? Identify the intervening commit where code that got cleaned up differently was introduced or removed and make the change to the deblobbing at that point; rinse and repeat. If differences remain that are not caused by the patches, it's something that changed in the scripts, possibly improving or correcting an earlier deblobbing error, e.g., something cleaned up that was found to be Free, or something that was missed in deblobbing, or a different way to clean it up. Such differences will likely be noticeable in the scripts. It's probably best to turn the difference in cleaning up into a separate commit for the purposes of the bisection, just in case it is the source of the issue being investigated. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer