The problem patch is in http://deb.debian.org/debian/pool/main/l/linux/linux_4.9.144... (I think)
"Commit 901e325f772f "ARM: bugs: add support for per-processor bug
checking" added a new member to struct processor. This structure
is always instantiated in built-in code and the new member is only
used in built-in code. Therefore we can safely add the new member
at the end instead.
Move it to the end and hide it from genksyms. Also hide it when
building modules, to make sure they really don't use it."
In Unstable, packages are promoted from Experimental as I understand it which is a comparatively easy threshold to get past. In Testing, packages are only promoted from Unstable if they 1) don't have any bugs open against them, and 2) there is not a freeze on. 50% of the time (1 year) there is a freeze on.
In Freeze, only bug fixes are promoted to Testing. New features have to take a number.
When the freeze is over, Testing is cut and becomes the new Stable. I might have described some part of this subtly wrong, but this is the Debian release management process in a nutshell. To read more: https://release.debian.org/
In short, "Stable" should be read like stable compound, not like we usually interpret it to mean "doesn't crash" in IT.
It's a side effect of not changing often, that it probably doesn't crash too much. The crashing bugs wouldn't have made it into testing, or through the testing/freeze process. Hopefully, at least.
I personally prefer to run Unstable on my developer machines, because it gets fixes more frequently:
> Security updates are made by the maintainer; they may not be effective on all architectures, and may be delayed. Packages uploaded may not meet release standards, but any breakage is expected to be fixed promptly. Updates are made by maintainers.
I don't think that's true, it's likely that the actual causes of crashes are better known and documented, I don't think there is a particular way you can make a software release be less likely compared to other releases of the same software.
> If you are planning big or disruptive change, check the timeline to see if it's still realistic to finish them before the transition freeze.
This might have been a better link to post. The freeze happens in stages "transition freeze / soft freeze / full freeze"
Anyway I phrased that all wrong. I meant to say, that if it doesn't crash as much for you, you can expect that to stay the same throughout the stable release. The changes are universally where the new bugs are coming from. So it follows that you should expect less new bugs, because there are so few changes allowed in the stable distro.
Security fixes and Updates are delivered separately. I don't know this process inside and out but I've been exposed to it for 20 years, here are some more good current links:
> Even stable is updated once in a while. Those updates are called "Point Releases". They usually incorporate the security fixes released until the time of the update and fixes for grave bugs in the current release.
The horse is "unstable'd", maybe another way of saying it. Unstable is developed outside of the stable release engineering process. That does not mean it's without safeguards. The unstable releases tend to be very stable. There are extra safeguards, and time-based safety measures that protect users of the Stable distribution. They say that Unstable might take longer to get fixes, and while that's likely true in the case of critical fixes with special attention, it's almost never true in practice other than that. Unstable receives fixes much more quickly, in general.
There actually used to be a "debian-volatile" project, too, for things like virus definitions that should be used in a stable distribution, and also didn't make sense to govern through the stable release process, but it is defunct now.
How can you declare something "stable" if you don't perpetually run tests to verify it is indeed "stable"?
And to state the obvious: certain bugs will lead to instability, non-deterministic, and undefined behavior - that's the very nature of things breaking down.
Of course that means it's about as stable as in not crashing as any other distro.
* a rough diagram: https://github.com/FOSDEM/video/tree/master/hardware
* the software running on them: https://github.com/FOSDEM/infrastructure/tree/master/ansible...
Your message also served as a reminder that I should really publish the laser cut box cutting and assembly info. I'll get to that eventually.
Edit: oh, FOSDEM was 2 weeks ago, not in the near future, so impact is less
Thanks for the hard work and for providing such a great event for free. And for the cool t-shirts :D
Maintainer: Debian Kernel Team <email@example.com>
Installed-Size: 4,466 kB
Download-Size: 1,300 kB
APT-Sources: http://raspbian.raspberrypi.org/raspbian stretch/main
armhf Packages Description: Linux support headers for userspace
development This package provides userspaces headers from the Linux
kernel. These headers are used by the installed headers for GNU libc
and other system libraries.
$ wget https://snapshot.debian.org/archive/debian/20181028T150508Z/...
$ dpkg -i linux-image-4.9.0-8-armmp-lpae_4.9.130-2_armhf.deb
and set the version on hold:
$ apt-mark hold linux-image-4.9.0-8-armmp-lpae
I imagine there could be a number of IOT, media or other devices unknowingly running Debian on ARM though; more than we realise.
I can't think of a better solution if the SBC is supported. What would you recommend as an alternative?
so does that mean they test the kernel but not their own patches to it? seems silly :D