![](https://seccdn.libravatar.org/avatar/b58101fb24c64d0ff1d0f918e61cedd2.jpg?s=120&d=mm&r=g)
Hallo Michael, hallo zusammen, Am Donnerstag, 6. Oktober 2016, 11:51:03 CEST schrieb Michael Born:
Ich kann ja verstehen, dass das backporten zu aufwändig ist. Aber, ner neuen Distribution so nen alten Kernel an die Backe zu hängen...
Ja, die Versionsnummer ist alt ;-) - aber wenn Du Dir das Kernel-Paket mal genauer ansiehst, wirst Du 4666 Patches finden. Ein Teil davon sind Bugfixes, der andere Teil sind Backports von Features aus neueren Kerneln. Der gleiche Kernel steckt auch im aktuellen SLE 12 SP 2 - das Kernel- Team bei SUSE hat dadurch eine Kernel-Version weniger zu pflegen. Ähnliches gilt auch für etliche andere Pakete in Leap: Wenn die Version aus SLE passt, wird sie übernommen (und spart Arbeit) - falls nicht, kann man aber problemlos neuere Versionen submitten [1]. Außerdem stecken in Leap viele Pakete, die nicht in SLE enthalten sind. SLE 12 SP 2wird AFAIK demnächst releast - übrigens _vor_ der 42.2, was die SLE-Benutzer quasi zu unseren Betatestern macht ;-))
PS: Beim MESA Bugreport habe ich mindestens einen Fehler gemacht. Ich hätte erwähnen sollen, dass MESA 12.0.3 bei mir (RX480) funktionierte. Die MESA 12git1 Änderungen sind also längst eingeflossen. Das ist also kein Argument, aber jetzt kann ich den Bug nicht mehr kommentieren
Doch, kannst Du. Auch in geschlossenen Bugs sind Kommentare möglich. Du kannst den Bug sogar auf REOPENED setzen, wenn Du es für nötig hältst. Ich habe das gerade in https://bugzilla.opensuse.org/show_bug.cgi?id=1003195 gemacht ;-)
und vermutlich brauche ich den Suse Leuten auch keine weitere Zeit klauen.
Naja, offizielles Release vs. tagesaktuelles Git ist schon ein deutlicher Unterschied. Das größte Problem dürfte sein, dass 42.2 inzwischen im Package Freeze ist - beta3 wurde gerade releast, am 18.10. gibt es den RC 1 [4]. Daher sind nur noch Bugfixes erwünscht, aber möglichst keine Versionsupdates (Ausnahmen bestätigen die Regel ;-) Gruß Christian Boltz [1] Been there, done that. SLE nutzt noch AppArmor 2.8.x (*autsch* [2]), für Leap habe ich 2.10.1 submitted. [2] Ich will nicht zu sehr ins Detail gehen, nur soviel: die aa-*-Tools wurden in 2.9 komplett neu geschrieben (in Python, bis 2.8 war es Perl). Du willst nicht wissen, wie viele Fehler im alten Perl-Code mir in dieser Zeit aufgefallen sind und in der neuen Version gefixt wurden ;-) [3] Das heißt natürlich auch, dass ich das Paket in Leap pflegen darf / muss, statt mich zurückzulehnen und das SLE-Paket zu genießen. Aus den genannten Gründen mache ich das aber _sehr_ gern. Auch aus Eigeninteresse, weil ich einige Server mit Leap (auch schon mit 42.2 beta) laufen habe und die AppArmor-Tools dort brauche ;-) [3] Das hatte ich auch dem Maintainer von AppArmor in SLE gesagt, aber er wollte nicht auf 2.9 updaten, das gerade rechtzeitig für SLE 12 fertig geworder wäre. Es hat nicht lange gedauert, bis er nach meiner Meinung zu einem Bugreport gefragt hat. Meine Antwort war dann nur a) fixed in 2.9 und b) told you so ;-) [4] https://en.opensuse.org/Roadmap -- Digital files cannot be made uncopyable, any more than water can be made not wet. [Bruce Schneier on `copy protection' schemes] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org