Flashtargets in Makefile umgeschrieben

[dietmarw]

wenn die drei zusätzlichen optionen aktiviert werden,
dann ist zb das enigma cramfs um ca. 200k zu groß für die newmake flash defaultgröße.

edit:
auch nur mit der ide option wird das enigma cramfs zu groß für die newmake standardgröße

edit2:
also gibts von mir erstmal kein "make everything" mehr,
sondern die targets einzelnd ohne enigma-cramfs
(nur wegen enigma-cramfs die part-größe für alle ändern, bzw. alle einzelnd configurieren, hab ich nicht vor)

[the_moon]

--enable-lirc: lirc wird eingebaut in YADD und Images.

Danke.

Hi,

ich habe da auch noch init.d script für lircd eingecheckt. start_lirc in MAIN Branche und ein Aufruf in "newmake" Branche. Ich weiss nicht ob es so passt. lircd wird gestartet wenn /var/etc/lircd.conf vorhanden ist.

[the_moon]

Hm,

gestern hab' ich irgendwas falsches gemacht. Ich habe unter cdk/root/etc/init.d "start_lirc" eingecheckt in HEAD (erstmal versehntlich in "newmake[/]" Branche, aber dann gelöscht und ins HEAD eingecheckt).

Heute versuche ich es mit cvs update -dCfr newmake[b/] auszuchecken, aber es geht nicht. Ich habe alles auser start_lirc. Wie könnte ich es korrigieren?

ich würde einen Rat sehr dankbar. Und vielleicht kann jemand mir sagen, wenn ich newmake Branch ausgecheckt habe mittels "cvs co -f r newmake", wie kann ich dann Änderungen in nicht "newmake" Dateien einchecken?

Wenn ich es einfach mit "cvs commit datei_not_in_branche.c" versuche, cvs sagt mir "no more in cvs, oder änliches.


Danke

Georg

[the_moon]

oops, habe übersehen. Sorry.

[Barf]

ich habe da auch noch init.d script für lircd eingecheckt. start_lirc in MAIN Branche und ein Aufruf in "newmake" Branche. Ich weiss nicht ob es so passt. lircd wird gestartet wenn /var/etc/lircd.conf vorhanden ist.

Ich bin leider nicht überzeigt. Erstmals gibt es schon ein Start von lircd (falls /var/tuxbox/config/lirc/lircd.conf vorhanden) in rcS.m4 (Zeile 154-155). Jetzt wird lircd auf zweit Plätze gestartet (aber mit unterschiedliche Konfigurationsfiles). Zweitens, Pfad des Konfigurationfiles: Laut Filesystem Hierarchy Standard wäre /etc eigentlich richtige Verzeichniss für Systemkonfigurationsfiles. Irgendwie hat sich /var/tuxbox/config[/subdir] anstatt sich etabliert. Über die Sinnvollkeit kann mann streiten, am mindestens hat "mann" seit Jahren /var/tuxbox/config benutzt, und Wiki beschreibt auch dies. Dateien wie passwd befinden sich bei Images/YADDs mit schreibbar /etc da, in Images mit /etc readonly sind sie gelinkt nach /var/etc. In jeden Fall sollen sie mit z.B. /etc/passwd "angesprochen" werden, nicht /var/etc/passwd. Zum letzten, start_lircd: Die meiste daemons von rcS werden einfach "rangeschmissen" von rcS, ohne Startskript. Einige Programme brauchen diverse "supportprogramme", z.B. neutrino. Andere Programmem, z.B. automountd, haben diverse Parameter, die irgendwie definiert werden muss. In Unterschied zu SysV-Systeme haben aber die meiste Programme nicht eigene start/stop-Skripte. Was bringt also start_lircd, mehr als ein [miss-]erfolgsmeldung?

Tut mir leid, dass ich so negativ klinge...

Ist der letzter Beitrag so zu verstehen dass das CVS-Problem sich gelöst hat?

[the_moon]

Tut mir leid, dass ich so negativ klinge...

Alles richtig. Ich habe einfach nicht gründlich genug startup Skripte eingeschaut und "erste" start von lirc übersehen. Dann habe ich einfach sshd als Beispiel genommen.

Ich mache alles wieder weg. Ich wollte blöss vor dem Wochenend endlich ein vollständiges Image bauen.

[Barf]

Es gibt eine neue configure-option --with-assume-kernelsources-old. Dadurch werden die Linuxkernelsources als "unendlich alt" betrachtet, und kein neukompilieren des Compilers und der glibc-Bibliothek wird durch ihre Timestamp ausgelöst.

Hintergrund: Beim Compilieren des gccs werden die Linuxkernelsources einbezogen. Deswegen hängt der Compiler von den Kernelsources ab. Falls diese sich ändern ist der Compiler out-of-date, und muss, a priori, neu gebaut werden, um sicher zu sein dass er up-to-date (konsistent mit den Kernelquellen) ist. Dies ist ein Fakt. Praktisch ist es oft so, dass mann oft davon ausgehen kann, dass nicht für den Kompiler relevantes sich geändert hat, und mann auf das Neukompilieren verzichten kann. Die Option --with-assume-kernelsources-old sagt make gerade dies: Betrachte die Kernelquellen als "unendlich alt".

(Ein ähnliches Problem stellt die C++-Sprache und die Includes dar. In den Includes stehen oft erhebliche klassenprivate Teilen. Nach Änderung, auch wenn sie nur klassenprivate Teile betreffen, müssen alle Klassen die die Includes benutzen neu kompiliert werden.)

Head-make ignoriert einfach diese Abhängigkeiten. Dies ist ein Fehler.

Ausserdem läuft --enable-ide, siehe http://tuxbox-forum.dreambox-fan.de/for ... hp?t=42489

[racker]

Dass ich dazu die nächste 6 Monate komme ist unwahrscheinlich.

Ist die Zeit so schnell vergangen?
Wenn noch eine configure-option dazukommt, wird es Zeit für ein "make menuconfig"

Egal, nachdem ich wieder das Diff anpassen musste...
So sieht meine bisherige Lösung aus (aktuelles Diff):

Code: Alles auswählen

diff -Naur a/cdk/configure.ac b/cdk/configure.ac
--- a/cdk/configure.ac	2006-08-26 16:10:03.000000000 +0200
+++ b/cdk/configure.ac	2006-08-26 22:03:49.000000000 +0200
@@ -51,11 +51,6 @@
 	AC_MSG_WARN([--with-targetruleset is obsolete; use --[[enable|disable]]-flashrules instead]);
 fi
 
-AC_ARG_WITH(assume-kernelsources-old,
-	[  --with-assume-kernelsources-old	Do not recompile due to new kernel sources],
-	[assume_kernelsources_old="yes"],[assume_kernelsources_old="no"])
-AM_CONDITIONAL(ASSUME_KERNELSOURCES_OLD,test "$assume_kernelsources_old" = "yes")
-
 AC_ARG_ENABLE(flashrules,
 	AS_HELP_STRING(--enable-flashrules,	enable rules for creating flash targets),
 	,[enable_flashrules=yes])
diff -Naur a/cdk/make/bootstrap.mk b/cdk/make/bootstrap.mk
--- a/cdk/make/bootstrap.mk	2006-08-26 16:10:03.000000000 +0200
+++ b/cdk/make/bootstrap.mk	2006-08-26 22:01:06.000000000 +0200
@@ -60,6 +60,7 @@
 KERNEL_BUILD_FILENAME = @DIR_linux24@/arch/ppc/boot/images/vmlinux.gz
 endif
 
+$(DEPDIR)/linuxheaders \
 $(DEPDIR)/linuxdir: $(KERNEL_DEPENDS) directories
 	$(KERNEL_PREPARE)
 	cp Patches/linux-$(KERNELVERSION).config $(KERNEL_DIR)/.config
@@ -92,11 +93,7 @@
 #
 # gcc first stage without glibc
 #
-if ASSUME_KERNELSOURCES_OLD
-$(DEPDIR)/bootstrap_gcc: @DEPENDS_bootstrap_gcc@ binutils | linuxdir
-else
-$(DEPDIR)/bootstrap_gcc: @DEPENDS_bootstrap_gcc@ binutils linuxdir
-endif
+$(DEPDIR)/bootstrap_gcc: @DEPENDS_bootstrap_gcc@ binutils linuxheaders
 	@PREPARE_bootstrap_gcc@
 	$(INSTALL) -d $(hostprefix)/$(target)/sys-include
 	ln -sf $(buildprefix)/linux/include/{asm,linux} $(hostprefix)/$(target)/sys-include/

Einzigster Nachteil ist, dass die Kernelsourcen 2x ausgepackt werden -
aber nur beim erstenmal.
Für mich die bessere Lösung, da ich die configure-optionen sowieso
wieder vergesse.

Head-make ignoriert einfach diese Abhängigkeiten. Dies ist ein Fehler.

Ich denke der "Head-Author" war sich dieser Problematik bewusst
und hat entsprechend die "ehernen Regeln" gebeugt.

[Barf]

Neue Option

--enable-nfsserver

läuft sowohl in YADD als auch in Images. Platzbedarf im Flash: etwa 210kB (bevor Kompression), in YADD deutlich mehr.

[Barf]

Ich habe ein neues Verzeichniss .../cdk/custiomization angelegt, und dadrin drei (z.Z.) Files die vielleicht beim Customization nützlig sein kann. Es ist

mkversion: Erzeigt die Neutrino-kompatible Versionsstring, von etwas mehr "zivilisierte" Eingangsparameter

nukegames: gamesplugins werden gelöscht. Typische Benutzung von root-neutrino-jffs2-local.sh.

nukelanguages: locale-Files, AUSSER die auf der Kommandozeile genannt, werden gelöscht. Typische Benutzung von root-neutrino-jffs2-local.sh.

Anrufbeispiele sind als Kommentare drin.

[Innuendo]

Code: Alles auswählen

   # Needless to say, this script will nuke all data on the disc.
  
  +echo "This command will initialize you hard disk. It will irrevocably"
  +echo "ERASE ALL DATA on the disk!! If this is what you want to do,"
  +echo "enter 3.1415926 to continue."
  +
  +read ans
  +if [ $ans = "3.1415926" ] ; then
  +    echo Continuing...
  +else
  +    echo "Bye!"
  +    exit 1
  +fi

passend dazu gibt es eine newmake rc



Innu

[Barf]

Tja, nicht ohne Unterhaltungswert!

Hat aber zwei Probleme: Erstmals muss der Benutzer die Zahlen mit der Tastatus eintippen, keine FB (oder click-n-pasten). Zweitens ist das Skript in HEAD nicht newmake eingecheckt. (Es gibt sonst kein init_hd.Skript in CVS; JtG-Riker hat sein nicht in (unser) CVS eingecheckt.)

[ed_2]

Neue Option

--enable-nfsserver

läuft sowohl in YADD als auch in Images. Platzbedarf im Flash: etwa 210kB (bevor Kompression), in YADD deutlich mehr.

Hi,

was bewirkt diese Option?
Baut sie einen NFSSERVER auf der Box wenn ja wie kann ich dann einen NFSServer konfigurieren?

Mfg

ed_2

[skydiver]

ich kann auch nur mutmaßen. sinn macht so ein ding sicherlich nur im zusammenhang mit der ide-geschichte. da da in der vergangenheit ja so einiges gelaufen ist, liegt der verdacht nache, dass da auf der box ein nfs-server läuft.
standardmäßig wird der nfs über die datei exports gesteuert.

[PT-1]

Da ich noch unter etwas Schlafmangel leide habe ich jetzt erst kapiert was Barf mit den Aufruf etc meint...

Unter /cdk/customization sind dies 3 neuen Files ...

Muss jetzt erstmal versuchen zu verstehen wie man diese aufruft.

Wie waere es denn z.B. auch mit einer Standard Sprache nach booten ..?

Viele unserer auslaendischen Mitlesern wuerden sich doch freuen wenn die Box nach Newmake Image gleich in deren Landessprache hochlaueft ...

[Barf]

Baut sie einen NFSSERVER auf der Box

Sonst wäre ja die Bezeichnung etwas irreführend

sinn macht so ein ding sicherlich nur im zusammenhang mit der ide-geschichte.

In der tat weigert sich der NFS-Server z.B. jffs2-Filesysteme zu exportieren.

standardmäßig wird der nfs über die datei exports gesteuert.

Soisses. Für Syntax und Semantik, siehe man exports auf einem Linuxrechner.

Wie waere es denn z.B. auch mit einer Standard Sprache nach booten ..?

Viele unserer auslaendischen Mitlesern wuerden sich doch freuen wenn die Box nach Newmake Image gleich in deren Landessprache hochlaueft ...

Über konstruktive Vorschläge wie dies bewerkstelligt werden kann wurde ich mich freue. Soo schlecht ist es, wie es ist, nicht: Falls neutrino.conf fehlt (="Auslieferungszustand") fragt neutrino als erstes für Sprache, Ähnliges gilt für Enigma.

[PT-1]

@Barf:

hier

per gewalt..

Code: Alles auswählen

@@ -3343,7 +3349,7 @@ 
CLocaleManager::loadLocale_ret_t loadLocale_ret = g_Locale->loadLocale(g_settings.language); 
if (loadLocale_ret == CLocaleManager::NO_SUCH_LOCALE) 
{ 
- strcpy(g_settings.language, "deutsch"); 
+ strcpy(g_settings.language, "english"); 
loadLocale_ret = g_Locale->loadLocale(g_settings.language); 
display_language_selection = true; 
} 
Binary files orig-cvs/apps/tuxbox/neutrino/src/neutrino.o and tuxbox-cvs/apps/tuxbox/neutrino/src/neutrino.o differ 
Binary files orig-cvs/apps/tuxbox/neutrino/src/system/libneutrino_system.a and tuxbox-cvs/apps/tuxbox/neutrino/src/system/libneutrino_system.a differ 
Binary files orig-cvs/apps/tuxbox/neutrino/src/system/localize.o and tuxbox-cvs/apps/tuxbox/neutrino/src/system/localize.o differ

[Nico 77]

Das ist doch Quark, deutsch ist default und das ist auch gut so.

[PT-1]

@Nico

Deutsch ist ja auch meine Hauptsprache aber stell dir mal vor es gibt auch noch andere Nationalitaeten..

Die Frage/Idee an Barf war ja dies z.B. beim Imagebauen gleich einzustellen, sprich ich baue mir mein Image gleich in English, Barf in Schwedisch oder wer auch immer.

[DieMade]

deutsch ist default

Merkt man.....*scnr*

[skydiver]

LOL diese Anglizismen sind mir einfach zu strange

[Barf]

Die Anglizismendiskussion habe ich hier weitergeführt. Hier ist es OT.

Idealerweise sollte der Imagebauer die Defaultsprache (sic!) festlegen können. Da sehe ich einige Möglichkeiten dies zu implementieren. Wichtig? Ganz und gar nix.

Unabhängig von alles anderem versteht der Durchnitts-Schmidt "Please select language" sicherlich besser als der Average-Jones "Bitte wählen Sie Sprache aus" versteht.

[Nico 77]

Meine Begründung liegt darin das sich fast ausschliesslich bis auf PT-1, Arzka und Barf nur deutsche Entwickler beteiligen.
Alles was sonst mal hier oder sonst wo gewesen ist verkommt in der Emu Scene.

Es besteht an Neutrino im Ausland kein Interesse so lange es ohne Laufvögel ist, hier wird es verteufelt und jetzt auf einmal will man so Leute das auch noch Mundgerecht machen.
Da wird deutlich gepatcht und gebaut was das Zeug hält also sollen sie ihre Standartsprache auch selber setzen!

*Respekt*

[PT-1]

Waere doch kein Problem wenn:

Keine Auswahl = Deutsche
Wenn Auswahl = Ausgewaehlte Sprache

[Barf]

Waere doch kein Problem wenn:

Keine Auswahl = Deutsche
Wenn Auswahl = Ausgewaehlte Sprache

Liegt nicht hier ein verständnissproblem vor? Genau so isses! Pseudocode:

Code: Alles auswählen

if neutrino.conf existiert
    hole locale davon
else
    auffordere Benutzer, in Defaultsprache, Sprache zu wählen
    if Abbruch
        locale = default
    else
        locale = Benutzerwahl
    fi
fi

Danach wird neutrino.conf gespeichert (angenommen dass der Benutzer nicht den Stecker zieht oder kill -9...). Also trifft dies nur für ganz jungfrauliche Images zu.

Sonst wäre es nicht schwierig, sowas (nicht getestet):

Code: Alles auswählen

	if (loadLocale_ret == CLocaleManager::NO_SUCH_LOCALE)
	{
		strcpy(g_settings.language, "deutsch"); // Fallback if rest fails
                FILE *f = fopen("/var/tuxbox/config/default.locale", "r");
                if (f) {
                       char loc[100];
                       int res = fscanf(f, "%s", loc);
                       if (res > 0)
                              strcpy(g_settings.language, loc);
                       fclose(f);                       
                } 
		loadLocale_ret = g_Locale->loadLocale(g_settings.language);
		display_language_selection = true;
	}

Übrigens benutze ich Neutrino in Deutsch: wie soll ich sonst mit Forumsteilnehmern und Wiki-Autoren kommunizieren? Ausserdem haben meine neue Images (und YADDS) ein neutrino.conf.