[VDR4Arch] Support für LTS-(Long-Term-Support)-Kernel?

Haue "lirc" runter und installiere nur "lirc-utils". Damit ist die Kernel-Abhängigkeit weg.

Mit dem neuen Lirc hat sich einiges an der Konfiguration geändert. Weiterhin habe ich mindestens einen Bug gefunden, der aber nur beim UDP-Treiber relevant ist. Der Kernel ist hier an der Stelle aber sicher nicht schuld.

Welchen LIRC-Empfänger nutzt du denn?

Was die Treiber-Pakete angeht muss sich Copperhead mal äußern. Er macht die Pakete und ich weiß, dass das auch jetzt bereits ne Menge Arbeit ist.

Prinzipiell könntest du dir die Pakete auf jedem Fall auch selber bauen. Es ist nur ein einziges PKGBUILD für die Treiber zuständig. Damit das gegen den LTS-Kernel baut muss es zwar minimal angepasst werden, aber das sollte eigentlich keine große Sache sein.

Zitat von connaisseur

Hhhhmmmm... Mit so einer Ansage wäre ich ein bißchen mehr "piano". Vielleicht hat sich der Anfragende ja was dabei gedacht, das entspr. Paket einzusetzen

Und ich habe mir durchaus etwas dabei gedacht als ich geraten habe "lirc" zu deinstallieren

Zitat

Den Atric IR-Einschalter v5. Der benötigt das "lirc_serial" Kernel-Modul, weil am ttyS0 hängend. Auf die Schnelle - die VDR-Maschine ist jetzt nicht greifbar - weiß ich nicht, in welchem Paket das lirc_serial-Modul enthalten ist (lirc, oder lirc_utils.

Ist schon seit geraumer Zeit im Paket "linux". Gehört also zum Kernel.

Zitat

Das habe ich mir schon gedacht. Aber vielleicht gibt es noch mehr (leise) Leidengenossen. Die dann ggf. das ArchLinux von der Platte hauen, und sich frustiert umorientieren müssen.

Letztlich gehört (meine persönliche Meinung) hier und da ein "lokales Downgrade" durchaus zum normalen "ArchLinux-Betrieb". Die Stabilisierungsphasen sind dort relativ kurz und so kommt es durchaus mal vor das ein neues Paket in einem bestimmten Fall zu Problemen führt.

Ich habe am Laptop auch schonmal mit Hilfe einer Boot-CD den Kernel downgraden müssen weil er nach dem Kernel-Update garnicht mehr gebootet hat. Das sollte nicht passieren, kommt bei ArchLinux, bedingt durch die kurzen Stabilisierungsphasen, aber dann und wann trotzdem vor.

Wenn es nicht der Kernel ist, der zwickt, dann ist es hier und da auch mal was anderes. Aktuell lasse ich keine Firefox-Updates mehr auf mein Laptop weil sonst kein Flash mehr geht. Da muss ich auch nochmal schauen woran das liegt...

Da der "lts-kernel" aber Bestandteil des offiziellen Repositories ist kann ich den Wunsch durchaus nachvollziehen.

Zitat von M-Reimer

Letztlich gehört (meine persönliche Meinung) hier und da ein "lokales Downgrade" durchaus zum normalen "ArchLinux-Betrieb".

Ja, leider. In 99% der Fälle gibt es keine Probleme. Mit 3.17 gibt es eben mal wieder Probleme. Das ist aber dann eher die Schuld von kernel.org.
Ich hatte übrigens auch Probleme mit einem neuen Modul namens efi_rtc. Auf meinem VDR macht es Ärger (fährt nicht mehr herunter) auf meinem Laptop läuft es perfekt. In der nächsten Kernelversion ist dieses Modul wieder weg.

Zitat von M-Reimer

Was die Treiber-Pakete angeht muss sich Copperhead mal äußern.

Immer muss ich mich äußern...
Ich hatte eigentlich schon darüber nachgedacht, das Treiberpaket ganz rauszunehmen, weil mir der Aufwand einfach zu groß ist. Ich muss für jede Kernelversion ein neues Paket schnüren, weil auch in den Minor-Versionen die API nicht kompatibel bleibt.
Ich bin also grundsätzlich nicht so begeistert...

Zitat von Copperhead

Immer muss ich mich äußern...

Du hast die Arbeit damit. Mir persönlich ist das einerlei weil ich ohnehin (schon weil ich Fehler in repo-make ausfindig machen will) aus den Sourcen baue. Dank "repo-make-custom.conf" habe ich dabei diverse Pakete (auch die Treiber-Pakete) ganz rausgemappt.

Mal ein ganz "dummer" Gedanke. Wo du die Treiber doch schon so schön "separiert" hast müsste doch ein DKMS-Paket machbar sein, oder?

Damit könnte man das Modul-Bauen "ganz frech" auf die Benutzerseite "abwälzen"

Zitat von M-Reimer

Mal ein ganz "dummer" Gedanke. Wo du die Treiber doch schon so schön "separiert" hast müsste doch ein DKMS-Paket machbar sein, oder?

Sicherlich geht das. Um sowas zu machen würde ich aber noch stärker aufräumen wollen. Das sollte ich sowieso mal tun.
Das Treiber PKGBUILD lädt schließlich den kompletten Kernel-Source runter. Benötigt wird nur ein winziger Bruchteil davon.

Das Kompilieren ist auch nicht das Problem. Ich muss es ja auch testen oder zumindest schauen, ob das Modul noch lädt und gerade die DVBSky Treiber brauchen bei jedem Major-Kernel-Update wieder etwas zusätzlichen Aufwand... (Das aber netterweise olebowle übernimmt)

Zitat von Copperhead

Ich hatte eigentlich schon darüber nachgedacht, das Treiberpaket ganz rauszunehmen, weil mir der Aufwand einfach zu groß ist. Ich muss für jede Kernelversion ein neues Paket schnüren, weil auch in den Minor-Versionen die API nicht kompatibel bleibt.Ich bin also grundsätzlich nicht so begeistert...

Kann ich durchaus nachvollziehen und könnte meiner Meinung nach auch auf die Nutzer abgewälzt werden. Die Wartung des/der PKGBUILD(s) könnte nach wie vor zentral passieren.

Ich seh den Vorteil von DKMS ehrlich gesagt nicht zum jetztigen makepkg. Klar wird das automatisch angestoßen und wenn es funktioniert ist es recht komfortabel. Allerdings ist es halt am Pacman vorbei (an #2985 tut sich ja leider auch nix) und wenn sich was größeres an den Kernel-Sourcen ändert funktioniert der Automatismus schon nicht mehr. Und das es mit 3.18 und folgenden zu Inkompatibiltäten mit zumindest den DVBSky-Treibern kommen wird ist absehbar, da einige Treiber in den Mainline-Kernel kommen.

Dann bräucht es jemanden der auf Zack ist und das DKMS, am besten noch vor bevor der Kernel nach core kommt, testet und gegebenfalls anpasst. Ob sich das jemand antun will?

Ich eigentlich nicht.

Dann schließen wir das doch einfach ab:

Kein Support für linux-lts in VDR4Arch

Sorry, aber gerade die von olebowle angesprochenen Neuerungen, werden im LTS-Kernel erst sehr verspätet ankommen und über die kommenden Probleme hatte ich noch gar nicht nachgedacht.