[Fli4l_dev] Informationen zu den wöchentlichen 4.0-Archiven vom 01.02.2019 (r55048)

[Alexander Dahl]

Moin,

B. Sprenger schrieb Mittwoch,  6. Februar 2019, 11:06 (CET):
>> Nein, das ist nicht der Grund. Mit jeder neuen Kernel-Version müssen
>> etliche Varianten (x86, x86_64, rpi, sunxi, free, non-free, virtual,
>> Kombinationen davon) gebaut werden. Das belastet unsere
>> Build-Infrastruktur (Speicher, Rechenzeit) und es würde im
>> SVN-Repository mit abgelegt werden, was _sehr_ viel Platz belegt
>> (kumuliert mittlerweile mehrere Gigabyte).
>
> Warum aktualisiert man dann nicht auf die Kernellinie 4.20.x (statt 
> 4.4.x). Ist das nicht sogar eine Longterm-Variante?

Nein, der neueste LTS ist 4.19, siehe
https://www.kernel.org/category/releases.html

Dort sieht man auch, wie lange die entsprechenden Kernel unterstützt
werden sollen, 4.19 bis Dezember 2020 und 4.4 bis Februar 2022, daher
waren wir bisher bei 4.4 geblieben. 

Wir diskutieren gerade wie wir mit den Kernelpaketen weiter verfahren.
Es gab auch schon von anderer Seite den Wunsch auf 4.19 zu gehen,
weniger wegen sicherheitskritischer Bugfixes, sondern eher wegen
Unterstützung für neue Hardware.

>>> Für uns "Normaluser" ist der damit faktisch außer Reichweite
>>> (irgendwann hat das Basteln einfach seine Grenzen...) und kann nicht
>>> getestest werden. Wem also bringt das überhaupt was? Das frage ich
>>> mich schon seit das hier so steht. :-)
>> 
>> Verständlich.
>
> Gibt es dazu irgendwo eine Anleitung, mit der man das selbst 
> ausprobierne kann

Die Developer-Dokumentation sollte das enthalten. Letztlich muss man
sich ein FBR aufsetzen, den Kernel aktivieren, alles durchkompilieren
und aus den entstandenen Binaries seine opt-Pakete generieren. Ich hab's
mir aber selbst auch noch nicht näher angeschaut, sondern das nur so dem
Gedächtnis wiedergegeben. Vielleicht mag Florian das näher erläutern?

Grüße
Alex

-- 
***** http://blog.antiblau.de/ *****************************
GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6