BusyBox 1.27.2 - neue Applets bringen neue Abhängigkeiten von der Kernel-Version

[PeterPawn]

Mit der BusyBox 1.27.2 sind ja einige neue Applets eingezogen, die auch in der Freetz-Konfiguration ausgewählt werden können, aber - je nach Kernel-Version der Box - auf nicht vorhandene Symbole und/oder Funktionen zurückgreifen wollen.

Zwei Punkte, an denen ich darüber gestolpert bin (ohne jeden Anspruch auf Vollständigkeit) sind die Applets

- nandwrite und
- nsenter

Beim "nandwrite" fehlt bei älteren Kernel-Versionen (konkret habe ich es bei der 2.6.39.3 der 6490 bemerkt) das Symbol "MTD_FILE_MODE_RAW" - das wurde auch bereits bemerkt und es gibt im BusyBox-Master einen entsprechenden Patch. Den muß man dann - zumindest für die Kernel-Versionen, wo er gebraucht wird, also in einem passenden Unterverzeichnis - noch zu den BusyBox-Patches hinzufügen, wenn man in das Problem läuft (die Voraussetzungen dafür sind sicherlich nicht alltäglich, weil man sowohl das Applet auswählen als auch auf einer älteren Kernel-Version der Box festhängen muß).

Ähnliches gilt für das neue Applet "nsenter" (eine Nachbildung aus dem util-linux-Paket) ... dort wird die "setns"-Funktion gebraucht und die gibt es erst ab Kernel-Version 3. Nun kann man als Benutzer/Anwender das Applet natürlich für die eigene Verwendung der BusyBox bei einem 2.6er-Kernel auch einfach nicht auswählen ... aber dabei fiel mir dann auch auf, daß es eben keinen Mechanismus gibt, der das in Freetz bisher auf die tatsächlich für den verwendeten Kernel verfügbaren Applets begrenzt, was da aus der BusyBox-Konfiguration generiert wurde und wird.

Man könnte zwar auch den Standpunkt vertreten, daß gleich die BusyBox vielleicht besser zusätzliche Abhängigkeiten für die neuen Applets einführen sollte, damit man z.B. mit einem Schlag alle Applets unterdrücken kann, die neuere Kernel-Funktionen brauchen ... aber ich weiß nicht, auf wieviel Gegenliebe man mit einem solchen Vorschlag stoßen würde und die Art und Weise, wie die BusyBox in Freetz verwendet wird (wo der Benutzer noch an der Auswahl der Applets ändern kann), ist schon etwas "speziell" - auch wenn man sich dazu selbst mindestens "advanced user competence" bescheinigen muß, damit die Konfigurationsmöglichkeiten für die BusyBox eingeblendet werden und dann könnte man bei den "Freetz-Machern" natürlich auf darauf bestehen, daß so etwas schon der Wahrheit entsprechen sollte.

Ich weiß also auch nicht, ob (oder gar wie) man das in Freetz lösen sollte oder ob es sogar ein generelles BusyBox-Problem ist (wobei die meisten BusyBox-Verwender halt wissen, für welche Kernel-Version sie die BusyBox brauchen und dann eben ihre Applet-Auswahl darauf beschränken können/müssen), aber es kann sich zu einer "pitfall" für jemanden auswachsen, der die Applet-Auswahl ändert (ohne wirklich zu wissen, was er da tut - das kommt ja durchaus mal vor, habe ich jedenfalls gelesen) und sich dann wundert, warum die BusyBox nicht mehr gebaut werden kann, obwohl er doch nur "gültige Einstellungen" (die auch noch erreichbar waren) geändert hat.

 

[er13]

Grundsätzlich besteht natürlich der Wunsch (nicht der Anspruch), dass alle angebotenen menuconfig-Optionen sowohl fehlerfrei bauen als auch fehlerfrei zur Laufzeit funktionieren. Dieser kann aber angesichts der vielen (oft nicht dokumentierten/erkennbaren/bekannten) Abhängigkeiten im allgemeinen leider nicht erfüllt werden.

Wenn dann eine Abhängigkeit erkannt wird, gibt es auch diverse Wege das damit verbundene Problem zu lösen:

• entweder einen Patch aufnehmen (sofern mit vertretbaren Aufwand möglich)
• oder eine bestimmte Option gänzlich ausschalten

Beides wird in Bezug auf busybox bereits gemacht.

Die beiden von Dir kommunizierten Probleme wurden in r14584 / dce7c55 behoben.

 

[PeterPawn]

Danke für's Beheben ... auch wenn Dir sicherlich klar ist, daß ich das eher als Dokumentation für Freetz-Benutzer geschrieben habe und weniger als "Aufforderung" zur Lösung des Problems (ich weiß auch, daß das IPPF kein Ticket-System ist).

Daß es nicht einfach ist, so etwas als Automatismus zu realisieren, ist mir durchaus bewußt - insbesondere im Angesicht des Anspruchs, auch noch uralte Versionen mit 2.6.irgendwas-Kernel für noch ältere Boxen mit 8 oder 16 MB NOR-Flash und 64 MB RAM aus denselben Quellen generieren zu wollen ... das traut sich vermutlich nicht einmal AVM wirklich zu, auch dort wird man sicherlich verschiedene Branches verwenden für unterschiedliche Stände (und Funktionsumfänge).

Zumal es ja bei einem aktuelleren Kernel 3.irgendwas vermutlich auch problemlos funktioniert, eine BusyBox mit allen denkbaren Applets zu erzeugen (zur Kontrolle) und umgekehrt vermutlich auch, eine BusyBox mit der "Standardauswahl" im Freetz-Trunk für die älteren Kernel- und uClibc-Versionen zu bauen (das wirst Du schon getestet haben im Zuge der Aktualisierung auf 1.27.2).

Ich bin ja auch nur darüber gestolpert, weil eben die 6490 (als tatsächlich noch aktuelles Modell, mit dem sich die Beschäftigung auch lohnt und die 6590 ist ja auch nichts anderes) noch einem 2.6.39-Kernel verwendet - bei den anderen Geräten klappt das auch mit meiner eigenen "Standardauswahl" an Applets (die ich auch gleich noch "manuell" setzen lasse, denn das ist mir über irgendwelche Kconfig-Abfragen oder Menüs viel zu anstrengend) ohne Beanstandungen.

===========================================================

Ich habe u.a. auch deshalb keinen Patch "vorbereitet" (und auch bisher nichts an meinem Freetz-Fork in dieser Richtung gemacht), weil wir auch hier wieder unterschiedliche Vorstellungen hätten, wie man das am besten umsetzt - ich hätte (und habe) den Patch (schon aus Gründen der Übersichtlichkeit der verbleibenden Patches) tatsächlich auf das beschränkt, was im BusyBox-Master im Upstream schon zu sehen ist (und ihn bei mir auch auf die konkreten, unterstützten Kernel-Versionen beschränkt, schließlich gibt es die versionsspezifischen Unterverzeichnisse auch für BusyBox-Patches bereits, wenn auch bisher keines für 2.6.39) - und nicht umgehend einen eigenen Patch daraus gemacht (auch wenn Du offenbar genauer nachgeforscht hast als D. Vlasenko, ab welcher Kernel-Version das Symbol den Namen geändert hat - vielleicht kommentierst Du ja seinen Patch am Master auch noch entsprechend auf der ML).

Wenn der Upstream-Patch so bleibt und in irgendeiner nächsten Version bereits enthalten ist, muß jedenfalls jeder andere als Du selbst das erst noch einmal genauer ansehen, wenn es zu einem Konflikt kommt - ist es derselbe Patch, klärt sich das auch ohne "genauere Analyse" auf den ersten Blick, daß der damit überflüssig wird. Das ist hier bei diesem "Mini-Patch" sicherlich noch kein wirkliches Problem - es ist (in meinen Augen jedenfalls) nur eine Frage der Arbeitsweise und die überträgt man dann (automatisch) selbst auch auf andere Patches, wo es schon schwerer zu erkennen ist und mehr Zeit braucht.

 

[er13]

vielleicht kommentierst Du ja seinen Patch am Master auch noch entsprechend auf der ML

Zwar nicht in Form eines Kommentars, aber als Patch. Mal schauen, was der Denys dazu sagt.

Es gibt in Freetz 2 busybox-Patches, die von Dir stammen. Könntest Du bitte bei Gelegenheit auf der busybox-ML nachfragen (bzw. gleich Patches schicken), ob diese upstream aufgenommen werden könnten? Danke!

 

[PeterPawn]

Ich habe es auf meine ToDo-Liste gesetzt und als Duplikat erkannt, weil es dort schon (leider sehr lange) stand - neben dem Patch für das "end of options" beim "expr"-Applet. Alles aber ohne exakte Deadline und max. mit "normal priority" - wenn die Patches für Dich zum Problem werden sollten, weil sie ohne Aufnahme beim Upstream natürlich die Zahl der Patches beim Review ebenso erhöhen wie das von mir nicht verstandene Vorgehen, schmeiß sie einfach wieder raus.

Am Ende stammen die auch nur aus der Zeit, wo die Möglichkeit über GitHub nicht (zumindest nicht in dem Maße wie jetzt) vorhanden war, andere Freetz-Nutzer mit zusätzlichen Patches aus einem VCS zu versorgen und es immer auf zusätzliche Patches (wie hier oben in #1, was ich eben über einen GitHub-Fork auch in Form eines direkt verwendbaren Branches als Diff zum Freetz-Master realisieren könnte) hinauslief, die dann kein Mensch mehr finden konnte in irgendwelchen IPPF-Beiträgen oder Trac-Tickets bzw. die dann nach dem nächsten "version bump" auch wieder ein "rediff" brauchten.

Unter diesem Gesichtspunkt war die Verwendung von GitHub und die unmittelbare Synchronisierung ein echter Fortschritt ... mal ganz abgesehen davon, daß der SVN-Server ja m.W. auch über den vServer für freetz.org läuft, auch wenn der vermutlich um einiges "stabiler" ist als der Webserver für die Trac-Site.

Du wirst Dich vielleicht auch noch an unsere Differenzen aus dem Ticket 2753 erinnern - da ging es um eine ältere Version der BusyBox und andere Fehler, aber auch bei der Benutzung des Trac-Servers anstelle des IPPF kamen wir nicht miteinander klar bzw. schrieben aneinander vorbei ... daher wirst Du mir die Beschränkung auf das IPPF als "Quelle" einer Fehlermeldung hoffentlich nachsehen, mal ganz abgesehen davon, daß die Benutzung von freetz.org ohnehin nur in gefühlten 50% eines Tages möglich ist, im Moment ist die Site (über HTTP, also der Trac-Server) schon wieder "down".

 

[er13]

schmeiß sie einfach wieder raus.

Nur die Ruhe, es hat keiner vor, irgendetwas rauszuschmeißen. Es war nur eine Bitte Deine bisher nur in Freetz gepflegten Änderungen upstream zu melden (so wie Du mich gebeten hast, die upstream-Variante der Problemlösung auf der ML zu kommentieren). Da die Änderungen von Dir stammen fand ich es unpassend, wenn ich es machen würde. Wenn sie upstream nicht aufgenommen werden, habe ich kein Problem damit, sie weiter in Freetz leben zu lassen, zumal Freetz sowieso auf eines der Patches inzwischen angewiesen ist (s. .. | $CKSUM -lp)

 

[PeterPawn]

Bin ja ruhig ... liegt mir halt auch "auf der Seele" und ist ein offener Punkt, den ich immer wieder aufschiebe; da war die "Erinnerung" halt das Bohren in der Wunde (und wirkte so ein kleines bißchen wie eine Retourkutsche, weil ich das "Erfinden" eines eigenen, vom BusyBox-Master abweichenden, Patches kritisiert hatte - aber ich habe das vielleicht auch nur falsch verstanden).

Wobei ich noch einen Punkt hätte ... der dreht sich um das OpenSSH-Paket. Nun paßt der weder hier hinein, noch will ich dafür einen neuen Thread aufmachen. Auch den Trac will ich nicht wirklich nutzen - selbst wenn es im Moment gerade mal wieder ginge, habe ich dort absichtlich keinen Account mehr und anonyme Tickets gibt es m.W. nicht (ggf. bitte korrigieren, wenn das falsch sein sollte).

Wie wäre es denn mit einer "Issue" im GitHub mit einer Beschreibung des Problems? Da kann man dann später auch noch einen Patch dranhängen, wenn man sich darauf verständigt hat, wie das Problem zu beseitigen wäre.

Wobei mich das wieder an den Punkt zurückführt, an dem eine - irgendwann mal angeschobene - Diskussion bisher auch zu keinem Abschluß kam ... welche Sprache sollte man dort verwenden?

Das krampfhafte Benutzen englischer Fehlermeldungen (weil GitHub so international ist) bringt ja am Ende auch nichts so richtig, wenn dann andere Freetz-Benutzer (ohne ausreichende Englischkenntnisse - und das soll es ja auch geben) nicht mehr erkennen, daß ein Ticket (oder eine "Issue" - ich bleibe mal bei "weiblich" für "Angelegenheit", wobei bei der Fülle von Bedeutungen auch jedes andere Geschlecht begründbar wäre) genau dasselbe Problem wiederspiegelt. Und der Löwenanteil der Freetz-User dürfte nun mal Deutsch lesen und schreiben ... auch im Trac war das ja sehr gemischt. Nur hat es da eben außerhalb des Projekts praktisch niemand mitbekommen ... was in GitHub sicherlich anders wäre.

Am besten wäre halt wirklich ein Umzug auf GitHub, dann kann man auch all die anderen "Funktionen" dort nutzen, bis hin zu einem "Code of Conduct", der auch die Fragen bzgl. der "prefered language" klären könnte. Aber damit das sinnvoll funktioniert, müßte man eben den Master-Status auf GitHub transferieren oder zumindest auch im SVN die Dateien in die Wurzel (und ggf. in Unterverzeichnisse) legen, die für diese Funktionen in GitHub gebraucht werden (bis hin zu GitHub Pages oder dem Wiki).

Ist im Moment halt etwas unklar, wie das nun weitergehen soll ... aber selbst die Leute, die den Trac für Fehlermeldungen nutzen würden, stehen ja deutlich zu oft vor dem Problem, daß der Server mal wieder gar nicht zu erreichen ist.

Das, was im Trac noch zur Strukturierung dienen mag (nämlich das kleinteilige Sezieren in jedes einzelne Problem, mit einem eigenen Ticket), macht das im Forum hier nur noch unübersichtlich - das kann also schon mal nicht als Ersatz dienen (jedenfalls nicht ernsthaft).

Da bleiben irgendwie nicht so viele Alternativen übrig ... höchstens noch die Frage, ob es GitHub sein muß oder nicht doch ein anderer Anbieter. Aber auch das dürfte sich schon vor langer Zeit entschieden haben, denn schließlich gibt es das Freetz-Repo auf GitHub ja bereits (mal von dem alten von Olistudent abgesehen, von dem ich nicht mal weiß, ob das noch über einen Hook aktualisiert wird).

Nur muß dann irgendwann auch mal der Ruck kommen ... sonst zieht sich das noch über Jahre (bis zum endgültigen Tod) auf einem SVN-Server hin und mit jedem weiteren Nutzer, der freetz.org mal wieder nicht erreichen kann, wenn er es gerade brauchen würde (und das nimmt ja eher exponentiell zu mit den Ausfällen) und sich deshalb noch mal genauer überlegt, ob es nicht doch der RasPi besser könnte (und der funktioniert dann mit jeder beliebigen AVM-Version), verliert Freetz weiter an Substanz und Nutzerzuspruch.

 

[PeterPawn]

Ich muß das noch einmal hervorkramen ... ich habe meinen Fork mal mit dem Trunk synchronisiert und dabei dann festgestellt, daß für die Nutzung des "nsenter"-Applets (bzw. erst mal für das erfolgreiche Erstellen einer BusyBox mit diesem Applet) im Freetz-Trunk immer noch der Patch der uClibc für die Unterstützung von "setns" fehlen würde: https://git.busybox.net/uClibc/commit/?id=5d5c77daae197b00f89ad1517ffb5a7a01a78cff

Das Experimentieren mit unterschiedlichen Namespaces ist halt auf dem Router auch recht interessant, weil man damit wieder eine gewisse Isolation zusätzlicher Prozesse vom Rest des Systems erreichen kann (und damit die Angriffsfläche wieder etwas verringert bzw. die Ausweitung erfolgreicher Angriffe erschwert, wenn andere Prozesse (von AVM) in anderen Namespaces nicht ohne weiteres erreichbar sind) ... ansonsten sind irgendwelche "Rechtestrukturen" ja nicht so sehr ausgeprägt auf einer FRITZ!Box und alle Versuche, da die "traditionellen" Mechanismen nachrüsten zu wollen, sind eher PITA.

 

[PeterPawn]

Wer die BusyBox samt "nsenter"-Applet (in unterstützten Versionen) bauen will, darf den Patch aus CS 14596 nicht 1:1 übernehmen ... das dort neu definierte Symbol "FREETZ_AVM_UCLIBC_1_0_14" gibt es ansonsten noch gar nicht und die Abhängigkeit für die Anzeige von "nsenter" in der Applet-Auswahl kann somit niemals erfüllt werden.

Man müßte also dann zumindest (wenn man das Applet haben will, was ja bisher nicht offiziell unterstützt wird in Freetz oder vielleicht doch (schließlich steht es in "generate.sh" explizit drin), aber nicht in dieser Version oder was auch immer die Änderungen im o.a. CS jetzt bedeuten mögen) das erwähnte Symbol noch definieren oder eben selbst den Patch für "setns" (den habe ich mir auch nicht selbst ausgedacht, den gibt es durchaus im offiziellen Git-Repo der uClibc: https://git.uclibc.org/uClibc/commit/?id=5d5c77daae197b00f89ad1517ffb5a7a01a78cff) auch für die uClibc 0.9.33.2 nachrüsten, wenn man mit einem aktuellen Release arbeiten will.

Die uClibc-ng 1.0.14 kommt auch bei AVM ja erst in der Labor-Reihe 06.98 zum Einsatz und da wird es schon auf absehbare Zeit noch genug Modelle geben, die nicht sofort mit FRITZ!OS 7 gesegnet - oder geschlagen, je nach Standpunkt - sein werden und weiterhin mit dem 3.10.73-Kernel (bei den VR9-Modellen, der GRX-Kernel ist etwas älter, enthält aber auch die "setns"-Unterstützung) und der uClibc 0.9.33.2 arbeiten werden.

Dazu würde es - beim "Eigenbau" - reichen, den verlinkten Patch einfach unter einem passenden Namen (wie hier als Beispiel zu sehen: https://github.com/PeterPawn/freetz/commit/b72e75ac6ed3e6cb6754ab84d17ed9b0fa4fabf1) in einem Verzeichnis abzulegen ... allerdings muß man dann auch seine eigene Toolchain erstellen lassen, denn die vorkompilierte für den Download enthält den Patch (beim derzeitigen Stand) dann eben auch nicht (und diese würde bei einem "normalen" Build auch nicht selbst erstellt bzw. neu gebaut).

Der Kernel (zumindest in ausgewählten Modellen, wo ich "Stichproben" gemacht habe - die Kernel-Konfiguration ist bei AVM aber i.d.R. auch für alle Modelle mit demselben Prozessor in dieser Hinsicht einheitlich) enthält die "setns"-Funktion aber auch dann, wenn man den originalen AVM-Kernel verwendet:

root@FB7490:/var/tmp $ grep setns /proc/kallsyms
80079ce0 T SyS_setns
80079ce0 T sys_setns
root@FB7490:/var/tmp $ uname -a
Linux FB7490 3.10.73 #1 SMP Fri Oct 27 15:34:52 CEST 2017 mips y
root@FB7490:/var/tmp $ /etc/version
113.06.92
root@FB7490:/var/tmp $

# uname -a
Linux fritz.box 3.10.12 #3 SMP Fri Oct 27 15:21:24 CEST 2017 mips GNU/Linux
# grep setns /proc/kallsyms
805710b4 T SyS_setns
805710b4 T sys_setns
# /etc/version
153.06.92
#

, man muß also für die Benutzung des Applets nicht auch noch den Kernel austauschen (bei VR9- und GRX5-Modellen) - damit sehe ich gar kein Risiko, wenn man (notfalls eben jeder Einzelne, der mit "nsenter" etwas testen oder experimentieren will ... die "Containerisierung" muß auch an der FRITZ!Box nicht spurlos vorübergehen) diese im Kernel bereits enthaltene Funktion auch noch in der C-Library nachrüstet.

Schade ist halt nur, daß man das im Moment dann nur in Kombination mit einer eigenen Toolchain machen kann (was Zeit beim Build kostet), wenn die Umsetzung im Trunk so bleiben sollte, wie sie sich jetzt präsentiert.

------------------------------------------------------------------------------------------------

Ob das Auftauchen von "FREETZ_AVM_UCLIBC_1_0_14" jetzt ein Zeichen dafür ist, daß da jemand doch daran baut, die Toolchain für die neue Labor-Reihe fit zu machen oder nicht, weiß ich auch nicht ... es sieht zumindest irgendwie danach aus, wenn das jetzt nicht eine komplette "Neuschöpfung" an dieser Stelle sein sollte.

 

[er13]

Zeichen richtig interpretiert. Ich habe lokal einen Stand mit Support für Fritz!OS 7.0X (bzw. für die entsprechenden Labors), allerdings im Zustand "baut noch nicht". Es ist also noch recht viel Arbeit und ich komme leider seit mehreren Wochen nicht dazu, weiter zu machen. Das Symbol mit 1.0.14 stammt aus diesem lokalen "Branch" (stammt in dem Sinne, ich weiß, wie dieses heißen wird).

Wie man an r14596 erkennen kann, plane ich nicht einen weiteren Patch für uClibc-0.9.33 aufzunehmen (geschweige denn für die uClibc-Versionen davor), damit nsenter dann auch auf Boxen mit uClibc-0.9.33 läuft. Daher das bewusste Setzen der Abhängigkeit auf 1.0.14 und damit das Beheben des vor dem Commit existierenden Problems, dass man nsenter auswählen kann, die busybox dann aber nicht baut. Ich hätte es analog den anderen Symbolen, die mittels FREETZ_DISABLE_OPTION_BY_MAKING_IT_DEPEND_ON_NONEXISTING_SYMBOL "ausgeschaltet" werden, machen können, der Effekt mit dem 1.0.14er-Symbol ist aber aktuell der gleiche. Der Vorteil für mich - beim Committen vom Fritz!OS-7.0x Branch muss ich an der Stelle nichts korrigieren.

 

[PeterPawn]

Schön zu hören, daß Du daran baust ... ich hatte mich zwar explizit positioniert, daß ich meinerseits da nichts dran machen werde, aber ich war halt etwas verunsichert, weil ich davon ausgegangen wäre, daß man (konkret Du) die Absicht irgendwo in einem Ticket kundtut, damit kein anderer (damit meine ich wieder explizit nicht mich) parallel daran arbeitet. Es ist aber auch gut möglich, daß ich dieses Ticket lediglich übersehen habe ... angesichts der Stabilität des Trac-Servers halte ich zur Zeit jede Erklärung für denkbar.

Das ständige Gegeneinander bzw. Nebeneinanderher bringt Freetz jedenfalls auch nicht wirklich weiter ... und ich weiß zwar so aus dem Stand auch nicht genau, wer da ansonsten noch in Frage käme und parallel zu Deinen eigenen Bemühungen arbeiten könnte, aber ich stimme natürlich (schon mal prophylaktisch) auch zu, daß ein Anderer das ja auch seinerseits in einem Ticket hätte "verkünden" können/sollen/müssen, wenn er sich an die Arbeit gemacht hätte. Dann hättest Du ihm/ihr sicherlich immer noch Bescheid sagen können ... wenn Du das entsprechend zeitnah mitbekommen hättest.

Komisch wirkt es halt von außen (zumindest auf mich und für meine Wenigkeit kann ich das sehr genau sagen und muß nicht spekulieren) schon ... erinnert etwas an das hier: https://en.wikipedia.org/wiki/One-man_band

--------------------------------------------------------------------------------------------------------------

Ansonsten habe ich meinen Beitrag auch bewußt so formuliert, daß er - soweit wie möglich jedenfalls - neutral gehalten war ... ich habe einen Lösungsweg aufgezeigt und darauf verwiesen, daß die Funktion im Kernel durchaus enthalten ist und man sie mithin in der C-Library auch gefahrlos nutzen kann. Gegebenenfalls mit der Beschränkung auf die entsprechenden Modelle bzw. Prozessoren - es wird vermutlich tatsächlich keine Sau interessieren, ob das in einer C-Library vor der 0.9.33 auch noch nachgerüstet wird oder nicht, weil dort schon die Kernelversionen gar nicht so wären, daß die Funktion überhaupt Sinn ergeben würde ... es hatte auch seinen Grund, warum ich diese meinerseits gar nicht erst erwähnt hatte.

Ich kenne bisher keine (von Freetz unterstützten, damit mir jetzt niemand etwas zur 7581 oder 7582 schreibt, falls die da ebenfalls im Topf wären) Geräte mit einem Kernel >= 3.0, die nicht auf VR9 oder GRX basieren würden oder eine uClibc vor 0.9.33 verwenden - es wäre also ohnehin höchst unvernünftig, wenn man

geschweige denn für die uClibc-Versionen davor

nicht ebenso sehen würde. Das gilt aber für die 0.9.33.2 ausdrücklich nicht - warum ich das meinerseits so sehe, habe ich auch noch dazugeschrieben und eine substantielle Gegenrede wäre mir entgangen.

Dann habe ich meinerseits noch einen Weg beschrieben, wie man dieses Applet (sofern man eigene Vorkehrungen gegen das bisher nicht genutzte Symbol trifft oder das komplette CS ignoriert, denn das macht ja nichts anderes, als dieses Symbol einzuführen und damit das "nsenter"-Applet dauerhaft (beim derzeitigen Stand im "Rest" von Freetz) auszublenden) auch ohne die Unterstützung im Trunk bauen kann. Punkt.

Mehr wollte ich gar nicht zum Ausdruck bringen ... Du wirst vermutlich wieder Deine Gründe haben, warum die Toolchain in Freetz nach Deiner Vorstellung für die derzeit als Release verfügbaren Versionen dieses Applet nicht unterstützen soll und ich habe gar nicht die Absicht, das mit Dir auszudiskutieren. An Unterschieden im Aufwand wird es ja hoffentlich nicht gelegen haben ... und wohl auch nicht daran, daß mit dem Erscheinen der 06.98-Labor-Reihe jetzt für die "alten" Versionen nichts mehr eingepflegt werden darf (zumindest wäre das neu).

Trotzdem war es mir ein Bedürfnis, in diesem Thread noch einmal darauf hinzuweisen, daß Dein letztes CS genau das Gegenteil von dem bewirkt(e), was ich in #8 vorgeschlagen habe - nicht zuletzt deshalb, weil Du im Commit-Text ja ausdrücklich auf meinen Beitrag Bezug nimmst und das könnte eben - zumindest nach meiner Lesart - irgendjemanden zu der Annahme verleiten, dieses CS würde das angesprochene Problem lösen.

Das macht es aber gerade nicht ... es blendet das Problem nur aus und verschiebt die Lösung auf das Erscheinen von FRITZ!OS 7 bzw. beschränkt die Benutzbarkeit des "nsenter"-Applets bis zu dessen Erscheinen (oder bis Deine Toolchain-Anpassungen spruchreif sind) und zusätzlich auch noch auf die Modelle, für die entsprechende Labor-Versionen verfügbar sind, solange es keine passende Release-Version für eine Box gibt.

 

[er13]

Ich betrachte den setns-Patch als reinen feature-Patch, er behebt eindeutig keinen Fehler, sondern fügt nur eine bisher in uClibc nicht umgesetze Funktion hinzu. Stand jetzt ist mir kein Paket bekannt, welches diese Funktion zwingend benötigen würde. Daher würde ich es bevorzugen, auf diesen Patch vorerst zu verzichten und das Problem des Nicht-Kompilierens dadurch zu "beheben", dass das sich nicht übersetzen lassende Applet erst gar nicht in menuconfig angeboten wird.

Sollten sich interessante Use-Cases ergeben (außer zum Ausprobieren/Spielen), so ist es durchaus möglich, dass ich meine Meinung ändere.

Edit: zu dem Zeitpunkt, zu dem ich angefangen habe, am Fritz!OS 7.0X Support zu arbeiten, ist der freetz.org-Server ständig down gewesen. Das ist der Grund, warum es kein Ticket gegeben hat, dem ich als Bearbeiter zugeordnet gewesen wäre. Dies wurde nun nachgeholt