[BobW]

Hallo,

das Bauen von dvb-vtuner scheitert derzeit, da das Makefile auf dvb-mb aufbeut, was aber nur mehr als "transitional package" existiert, da ja dvb-mb und auch dvb-mbe durch die Kernel-Module ersetzt werden.

Damit scheitert natürlich auch dvb-autodetect, das dvb-vtuner einbezieht.

Das vorübergehende Entfernen von des dvb-vtuner Ordners lässt dvb-autodetect ohne Probleme durchlaufen.

Schöne Grüße aus Wien
BobW

[P3f]

Hallo BobW,

wir hatten bis gestern Abend noch ein Problem mit der Integration vom vtunerc-Modul in die Kernelsourcen. Das konnte aber geklärt werden, und danach hatte ich auch das dvb-vtuner Paket korregiert. Es basiert nicht mehr auf dvb-mb, sondern ebenfalls auf den Kernel

Im Git ist auch das geänderte Makefile für dvb-vtuner enthalten, kannst Du bitte deine Develumgebung aktualisieren? Oder habe ich da noch etwas übersehen?

Danke, auf jeden Fall für die Erklärung die ja ansonsten korrekt waren.

Gruß,

Pit

[BobW]

Hallo Pit,

habe das Paket gerade neu geholt. Jetzt muss wohl auch noch den kernel neu holen, da das Modul vtunerc nicht gefunden wird. Dann muss ich eben nochmal von vorne anfangen.

Danke für die Info.

BobW

[P3f]

Hallo BobW,

entschuldigung, das Du da noch auf der Suche warst... Aber das mit dem vtunerc-Modul war das "letzte" bekannte offene Modul was uns noch fehlte.

Wir sind halt massiv am umbauen gewesen, damit wir die DVB-Kernel sourcen sauber inkludiert bekommen. Das sollte nun aber funktionieren. Ein Test ist natürlich immer willkommen.

Danke, auch für Deine Geduld und Unterstützung.

Pit

[BobW]

Hallo Pit,

der Test ist leider schiefgegangen. Habe es zuerst mit einem git pull im kernel-Verzeichnis probiert und den kernel neu bauen lassen, aber das frisch gezogene dvb-vtuner hat das Modul nicht gefunden.

Ein zweiter Test mit rm -rf kernel, anschließendem checkout und neu Bauen hat dasselbe Ergebnis gebracht.

Code: [Select]

mkfrank@msi-stretch:~/MLD-5.4/dvb-vtuner$ make
dvb-vtuner:
  Build package: dvb-vtuner
          Modul nicht gefunden: vtunerc
          Modul Verzeichnis nicht gefunden: drivers/media/vtuner
/bin/bash: package/data/lib/modules/4.10.17.199.20/modules.dvb-vtuner: Datei oder Verzeichnis nicht gefunden
find: ‘package/data/lib/modules/4.10.17.199.20/kernel’: Datei oder Verzeichnis nicht gefunden
Makefile:13: die Regel für Ziel „package/data“ scheiterte
make[1]: *** [package/data] Fehler 1
Ihr Branch ist auf dem selben Stand wie 'origin/master'.
mkfrank@msi-stretch:~/MLD-5.4/dvb-vtuner$

BobW

Edit: Nach einigem Herum-googeln scheint es so, dass vtuner NICHT Teil des Kernels ist. Das Projekt auf google.code scheint tot zu sein.
Allein hier https://github.com/timehlers/vtuner.git gibt es eine Kopie, die aber auch schon sechs, sieben Jahre alt ist.
Ob es das Modul in den mb/mbe Paketen gibt, habe ich noch nicht überprüft.

Edit 2: vtuner ist im ehemaligen dvb-mbe Paket enthalten.

[rfehr]

Hallo Pit,

der Test ist leider schiefgegangen. Habe es zuerst mit einem git pull im kernel-Verzeichnis probiert und den kernel neu bauen lassen, aber das frisch gezogene dvb-vtuner hat das Modul nicht gefunden.

Ein zweiter Test mit rm -rf kernel, anschließendem checkout und neu Bauen hat dasselbe Ergebnis gebracht.

Code: [Select]

mkfrank@msi-stretch:~/MLD-5.4/dvb-vtuner$ make
dvb-vtuner:
  Build package: dvb-vtuner
          Modul nicht gefunden: vtunerc
          Modul Verzeichnis nicht gefunden: drivers/media/vtuner
/bin/bash: package/data/lib/modules/4.10.17.199.20/modules.dvb-vtuner: Datei oder Verzeichnis nicht gefunden
find: ‘package/data/lib/modules/4.10.17.199.20/kernel’: Datei oder Verzeichnis nicht gefunden
Makefile:13: die Regel für Ziel „package/data“ scheiterte
make[1]: *** [package/data] Fehler 1
Ihr Branch ist auf dem selben Stand wie 'origin/master'.
mkfrank@msi-stretch:~/MLD-5.4/dvb-vtuner$

BobW

Edit: Nach einigem Herum-googeln scheint es so, dass vtuner NICHT Teil des Kernels ist. Das Projekt auf google.code scheint tot zu sein.
Allein hier https://github.com/timehlers/vtuner.git gibt es eine Kopie, die aber auch schon sechs, sieben Jahre alt ist.
Ob es das Modul in den mb/mbe Paketen gibt, habe ich noch nicht überprüft.

Edit 2: vtuner ist im ehemaligen dvb-mbe Paket enthalten.

Hi BobW,

irgend etwas stimmt mit deinen Sourcen nicht,
da die 5.4 unstable einen 4.14.2 Kernel einsetzt.

Und in deinem Log in 4.10.17 ??

Gruß,
  Roland

[P3f]

Hi BobW,

Kann es sein, das Du nicht bei X86 Umgebung bist?  Wir sind im Moment massiv im Umbruch und im Kernelpaket ist u.a. Ein Patch für den vtunerc drin, halt aktuell noch nicht in den arm -Umgebungen. Das kommt noch...

Ansonsten stehe ich vor einem Rätsel, da auch im GIT der Patch und die Anpassung im dvb-vtuner Paket sichtbar sind.

Gruß,

Pit

[BobW]

Hi Pit,

ich bin im x86_64 Pfad der 5.4 unstable.

Code: [Select]

mkfrank@msi-stretch:~/MLD-5.4$ cat Makefile.config
.SILENT:
DISTRI_VER = 5.4
CLASS = unstable
mkfrank@msi-stretch:~/MLD-5.4$

Ich habe eben nocheinmal versucht, den kernel mittels git pull auf den neuesten Stand zu bringen. Ein vtuner-patch ist allerdings nicht zu sehen:

Code: [Select]

mkfrank@msi-stretch:~/MLD-5.4$ cd kernel
mkfrank@msi-stretch:~/MLD-5.4/kernel$ git pull
Bereits aktuell.
mkfrank@msi-stretch:~/MLD-5.4/kernel$ ls -l src
insgesamt 812
-rw-r--r--  1 mkfrank mkfrank   4560 Nov 28 17:23 10_linux_vdr-shield.patch.rpi.disable
-rw-r--r--  1 mkfrank mkfrank    555 Nov 28 17:23 11_linux_fbtft.patch.rpi.disable
-rw-r--r--  1 mkfrank mkfrank    548 Nov 28 17:23 12_linux_ignor_buggy_compiler.patch.rpi
-rw-r--r--  1 mkfrank mkfrank   1067 Nov 28 17:23 13_linux_powerled.patch.wtk
-rw-r--r--  1 mkfrank mkfrank  15077 Nov 28 17:23 15_linux_sunxi_ir.patch.bpi
-rw-r--r--  1 mkfrank mkfrank 156614 Nov 28 17:23 16_linux_code.patch.wtk
-rw-r--r--  1 mkfrank mkfrank    753 Nov 28 17:23 17_linux_sunxi_csc.patch.bpi
-rw-r--r--  1 mkfrank mkfrank    518 Nov 28 17:23 18_linux_wetekplay_dtd.patch.wtk
-rw-r--r--  1 mkfrank mkfrank  12434 Nov 28 17:23 19_linux_alx_wol.patch.x86
-rw-r--r--  1 mkfrank mkfrank    721 Nov 28 17:23 20_linux_ati_remote.c.patch.x86
-rw-r--r--  1 mkfrank mkfrank    617 Nov 28 17:23 21_linux_sid_Makefile.patch.x86
-rw-r--r--  1 mkfrank mkfrank   1186 Nov 28 17:23 22_linux_dvb-s2-4650.patch.rpi
lrwxrwxrwx  1 mkfrank mkfrank     13 Nov 28 17:27 linux -> linux-4.10.17
drwxr-xr-x 25 mkfrank mkfrank   4096 Nov 28 17:27 linux-4.10.17
-rw-r--r--  1 mkfrank mkfrank  85092 Nov 28 17:23 linux.config.bpi
-rw-r--r--  1 mkfrank mkfrank 131415 Nov 28 17:23 linux.config.rpi
-rw-r--r--  1 mkfrank mkfrank 131451 Nov 28 17:23 linux.config.rpi2
-rw-r--r--  1 mkfrank mkfrank  96982 Nov 28 17:23 linux.config.wtk
-rw-r--r--  1 mkfrank mkfrank 127267 Nov 28 17:23 linux.config.x86
lrwxrwxrwx  1 mkfrank mkfrank     43 Nov 28 17:26 linux.txz -> /home/mkfrank/.cache/mld//linux-4.10.17.txz
drwxr-xr-x  2 mkfrank mkfrank   4096 Nov 28 17:26 locale
-rw-r--r--  1 mkfrank mkfrank    649 Nov 28 17:23 README
mkfrank@msi-stretch:~/MLD-5.4/kernel$

Und damit auch wirklich jede Fehlerquelle ausgeschlossen ist, habe ich eine neue 5.4 gezogen, die Makefeil.config nicht verändert und ein make checkout_base laufen lassen:

Code: [Select]

mkfrank@msi-stretch:~$ cd MLD-Test-5.4/
mkfrank@msi-stretch:~/MLD-Test-5.4$ cat Makefile.config
.SILENT:
mkfrank@msi-stretch:~/MLD-Test-5.4$ cd kernel
mkfrank@msi-stretch:~/MLD-Test-5.4/kernel$ ls -l src
insgesamt 808
-rw-r--r-- 1 mkfrank mkfrank   4560 Nov 28 23:01 10_linux_vdr-shield.patch.rpi.disable
-rw-r--r-- 1 mkfrank mkfrank    555 Nov 28 23:01 11_linux_fbtft.patch.rpi.disable
-rw-r--r-- 1 mkfrank mkfrank    548 Nov 28 23:01 12_linux_ignor_buggy_compiler.patch.rpi
-rw-r--r-- 1 mkfrank mkfrank   1067 Nov 28 23:01 13_linux_powerled.patch.wtk
-rw-r--r-- 1 mkfrank mkfrank  15077 Nov 28 23:01 15_linux_sunxi_ir.patch.bpi
-rw-r--r-- 1 mkfrank mkfrank 156614 Nov 28 23:01 16_linux_code.patch.wtk
-rw-r--r-- 1 mkfrank mkfrank    753 Nov 28 23:01 17_linux_sunxi_csc.patch.bpi
-rw-r--r-- 1 mkfrank mkfrank    518 Nov 28 23:01 18_linux_wetekplay_dtd.patch.wtk
-rw-r--r-- 1 mkfrank mkfrank  12434 Nov 28 23:01 19_linux_alx_wol.patch.x86
-rw-r--r-- 1 mkfrank mkfrank    721 Nov 28 23:01 20_linux_ati_remote.c.patch.x86
-rw-r--r-- 1 mkfrank mkfrank    617 Nov 28 23:01 21_linux_sid_Makefile.patch.x86
-rw-r--r-- 1 mkfrank mkfrank   1186 Nov 28 23:01 22_linux_dvb-s2-4650.patch.rpi
-rw-r--r-- 1 mkfrank mkfrank  85092 Nov 28 23:01 linux.config.bpi
-rw-r--r-- 1 mkfrank mkfrank 131415 Nov 28 23:01 linux.config.rpi
-rw-r--r-- 1 mkfrank mkfrank 131451 Nov 28 23:01 linux.config.rpi2
-rw-r--r-- 1 mkfrank mkfrank  96982 Nov 28 23:01 linux.config.wtk
-rw-r--r-- 1 mkfrank mkfrank 127267 Nov 28 23:01 linux.config.x86
drwxr-xr-x 2 mkfrank mkfrank   4096 Nov 28 23:01 locale
-rw-r--r-- 1 mkfrank mkfrank    649 Nov 28 23:01 README
mkfrank@msi-stretch:~/MLD-Test-5.4/kernel$

Das Ergebnis ist dasselbe. Einzig auffällig ist, dass kein Patch Nummer 14 dabei ist.

Schöne Grüße
BobW

[rfehr]

Hi BobW,

ich glaube ich habe es, du bist bestimmt noch auf dem 'master' Branch,
und nicht auf 'unstable', beim Kernel, kann das sein ?

Gruß,
  Roland

[BobW]

Hallo Roland,

ich bin dort, wo ich nach dem Checkout eben lande. Zumindest war das bisher so, dass nach dem ersten Checkout immer der neueste Zweig/Unstable "voreingestellt" war und man durch Anpassen der Makefile.config in einen anderen Zweig wechseln konnte.

Sollte sich dieses Verhalten geändert haben, dann bitte ich um Anweisungen, wie ich zu 5.4 Unstable komme.

"git branch" liefert jedenfalls das:

Code: [Select]

mkfrank@msi-stretch:~/MLD-5.4$ git branch
* master
mkfrank@msi-stretch:~/MLD-5.4$

Schöne Grüße
BobW

[rfehr]

Hi BobW,

gehe mal ins 'kernel' Verzeichnis,
dort dann mal ein git branch.

mit git checkout unstable müsstes du auf den 'unstable' Brnach vom Kernel kommen.

Gruß,
  Roland

[BobW]

Hallo Roland,

ja, das hat den Zweig gewechselt. Jetzt ist auch der Patch für vtuner vorhanden.

Code: [Select]

mkfrank@msi-stretch:~/MLD-5.4/kernel$ git branch
* master
mkfrank@msi-stretch:~/MLD-5.4/kernel$ git checkout unstable
Branch unstable konfiguriert zum Folgen von Remote-Branch unstable von origin.
Zu neuem Branch 'unstable' gewechselt
mkfrank@msi-stretch:~/MLD-5.4/kernel$ git pull
Bereits aktuell.
mkfrank@msi-stretch:~/MLD-5.4/kernel$ git branch
  master
* unstable
mkfrank@msi-stretch:~/MLD-5.4/kernel$ ls -l src
insgesamt 920
-rw-r--r--  1 mkfrank mkfrank   4560 Nov 28 17:23 10_linux_vdr-shield.patch.rpi.disable
-rw-r--r--  1 mkfrank mkfrank    555 Nov 28 17:23 11_linux_fbtft.patch.rpi.disable
-rw-r--r--  1 mkfrank mkfrank    548 Nov 28 17:23 12_linux_ignor_buggy_compiler.patch.rpi
-rw-r--r--  1 mkfrank mkfrank   1067 Nov 28 17:23 13_linux_powerled.patch.wtk
-rw-r--r--  1 mkfrank mkfrank  15077 Nov 28 17:23 15_linux_sunxi_ir.patch.bpi
-rw-r--r--  1 mkfrank mkfrank 156614 Nov 28 17:23 16_linux_code.patch.wtk
-rw-r--r--  1 mkfrank mkfrank    753 Nov 28 17:23 17_linux_sunxi_csc.patch.bpi
-rw-r--r--  1 mkfrank mkfrank    518 Nov 28 17:23 18_linux_wetekplay_dtd.patch.wtk
-rw-r--r--  1 mkfrank mkfrank  12434 Nov 29 08:09 19_linux_alx_wol.patch.x86
-rw-r--r--  1 mkfrank mkfrank    721 Nov 29 08:09 20_linux_ati_remote.c.patch.x86
-rw-r--r--  1 mkfrank mkfrank    617 Nov 29 08:09 21_linux_sid_Makefile.patch.x86
-rw-r--r--  1 mkfrank mkfrank   1186 Nov 28 17:23 22_linux_dvb-s2-4650.patch.rpi
-rw-r--r--  1 mkfrank mkfrank   8245 Nov 29 08:09 23_linux_dvb_dib0700.patch
-rw-r--r--  1 mkfrank mkfrank  38936 Nov 29 08:09 23_linux_dvb_tda18250.patch                                                                                                     
-rw-r--r--  1 mkfrank mkfrank  47150 Nov 29 08:09 24_linux_dvb_vtunerc.patch                                                                                                     
lrwxrwxrwx  1 mkfrank mkfrank     13 Nov 28 17:27 linux -> linux-4.10.17                                                                                                         
drwxr-xr-x 25 mkfrank mkfrank   4096 Nov 28 17:27 linux-4.10.17                                                                                                                   
-rw-r--r--  1 mkfrank mkfrank  85092 Nov 29 08:09 linux.config.bpi                                                                                                               
-rw-r--r--  1 mkfrank mkfrank 131415 Nov 29 08:09 linux.config.rpi                                                                                                               
-rw-r--r--  1 mkfrank mkfrank 131451 Nov 29 08:09 linux.config.rpi2                                                                                                               
-rw-r--r--  1 mkfrank mkfrank  96982 Nov 29 08:09 linux.config.wtk                                                                                                               
-rw-r--r--  1 mkfrank mkfrank 139194 Nov 29 08:09 linux.config.x86                                                                                                               
lrwxrwxrwx  1 mkfrank mkfrank     43 Nov 28 17:26 linux.txz -> /home/mkfrank/.cache/mld//linux-4.10.17.txz                                                                       
drwxr-xr-x  2 mkfrank mkfrank   4096 Nov 28 17:26 locale                                                                                                                         
-rw-r--r--  1 mkfrank mkfrank    649 Nov 28 17:23 README                                                                                                                         
mkfrank@msi-stretch:~/MLD-5.4/kernel$

Heißt das jetzt, dass für jedes Paket manuell auf "unstable" gewechselt werden muss, um eine konsistente Version der 5.4/unstable zu erhalten?
Ich hatte die entsprechenden Einstellungen vorher in der Makefile.config, nur haben die mich nicht zu diesem Zweig gebracht.

BobW

[rfehr]

Hi BobW,

soweit ich es aus dem Kopf weiß, haben wir nur für den kernel einen 'unstable' Branch angelegt,
um dort die neuen Kernel Version testen zu können, bei den anderen Paketen haben wir keinen Branch drin.

Gruß,
  Roland

[BobW]

Hallo Roland,

zuerst mal vielen Dank für die Hilfe.

Zum Abschluss noch eine kleine Frage: Hätte ich das irgendwie mitbekommen können, z.B. über die News?

BobW

[rfehr]

Hi BobW,

nein leider nicht, das haben wir nicht bekannt gemacht,
sollten wir vieleicht mal überdenken, ob wir das irgendwie händeln können.

Gruß,
  Roland