Beiträge von Igel1954

    Ich werd auch mal abwarten wie es mit LO weitergeht.


    Ich hab mit StarOffice unter OS2, inclusive Betatests, angefangen, später von OS/2 auf Linux gewechselt und nach dem Verkauf von SO an SUN auf OO und später auf LO umgestiegen.

    Problem hat sich erledgt. Ich hab die Ursache gefunden, warum keine Anzeige erfolgte.


    Es lag an meiner conky.conf, die 2 Zeilen erhielt, um die externe IPV4 und IPV6-Adresse anzuzeigen.


    Das Problem waren die beiden foigenden Anweisungen:

    wget http://v4.ipv6.com/api/myip.php -q -O -

    wget http://v6.ipv6.com/api/myip.php -q -O -


    Das hat die alte Version von Conky (1.13) unter LEAP 15.6 nicht gestört, sie hat einfach in den beiden Zeilen nix angezeigt. Ich musste die beiden Zeilen löschen und jetzt ist alles sichtbar.


    Ich hab jetzt die Version 1.22 aus dem Monitoring-Repo (war Vorschlag von Sauerland) laufen.


    Die Webseite ipv6.com gibt es zwar noch, aber die haben wohl das API abgeklemmt, es gibt auch keinen Hinweis auf das Vorhandensein des APIs.

    Sauerland Danke für den Tipp mit dem Repo.

    Hab conky jetzt aus dem Repo installiert, aber es will noch nicht so richtig.


    Ich bekomme beim Start aus der Konsole eine Meldung, die mich verwirrt:


    In der conky.conf steht aber background = false-


    Fehlermeldungen kommen keine.

    Ich habe jetzt erfolgreich alle 3 PCs in meinem Haushalt auf LEAP 16.0 per manuellem Upgrade umgestellt.


    Das einzige Problem, was ich noch lösen muss: CONKY läuft unter Wayland irgendwie nicht. Auch die Tipps für die cony.conf aus dem Netz, wie out-to-wayland=true kennt Conky (noch) nicht.

    Danke Sauerland,


    sorry, dass ich jetzt erst reagiere, aber ich muss eine Zwangspause vom Bildschirm einlegen. Ich soll bis zur Augen-OP (grauer Star) maximal 1 Std. am Tag am Bildschirm sitzen, die Ziet am Smartphone zählt auch. Ihc hatte es die letzten Tage mit der Bildschirm zeit etwas übertrieben.


    Der Unterschied zwischen dem RPM mit den Sourcen und dem RPM mit den Binaries war mit eigentlich schon klar.


    Das ist das SRC.RPM auspacken und dann den SPEC-File und den Source-file in die entsprechenden Unterverzeichnesse kopieren und dann bauen kann, ist mir gestern nicht mehr in mein Hirn gekommen. Ebenso die unterschiedliche Verwendung von rpmbuild --rebuild und rpmbuild -ba war gestern wohl für mein vernageltes Hirn nicht mehr greifbar.


    Jetzt weiß ich aber, wie ich "mein" REXX unter Linux gebaut bekomme. Werde ich in den nächsten Tagen dann mal richtig in Angriff nehmen.

    Sauerland

    Das hab ich schon vergeblich versucht. Ich bekomme das spec-file im src.rpm nicht editiert, bzw. hab keine Ahnung wie ich den File im RPM korrigieren kann, ohne das RPM zu zerstören.


    Ich hab den File aus src.rpm mit ARK entpackt, kann ihn dann editieren, bekomme ihn aber nicht wieder zurück ins src.rpm. Gibt es da eine spezielle Möglichkeit im src.rpm zu editieren, oder ist das egal, dass es auch noch einmal außerhalb des src.rpm liegt?

    Hallo Luigi,


    das Repo hatte ich gar nicht auf dem Schirm. Ich hab mir gerade mal das Regina-Rexx-RPM aus diesem Repo angeschaut. Das fehlt das addon/libregutil auch.

    Die Struktur ist auch etwas anders, keine /usr/lib64 . Hier sollte das Unterverzeichnis addons mit dem libregutil liegen. Die libregina* in /usr/lib64 fehlen auch.


    Bei Regina-REXX Version 3.9.1 legt das Addon-Verzeichnis noch unter /usr/share/Regina-REXX/, bzw. ist es beim Upgrade aus einer verherigen Leap15.x erhalten geblieben und ich nur den Link auf das libregutil neu angelegt.


    Ich hab mit Sicherheit nicht alle, außerhalb des OSS-Repos, gebauten Regina-REXX-RPMs gefunden. Daher wollte ich es aus dem src.rpm selber bauen.


    Ich hab mir dafür extra meine virtuelle Maschine nochmal auf Leap 15.6 zurück gesetzt, um das Bauen des RPM zu probieren.

    Wenn ich es unter 15.6 schaffe, dann will ich die virtuelle Maschine wieder auf 16.0 upgraden und das ganze dann noch mal durchführen. Das dann erzeugte RPM wandert dann auf meinen DesktopPC, nachdem ich dann auf 16.0 gehoben habe.


    Außerdem lerne ich gerne nach was dazu und wäre dann vor allem bei REXX in der Lage mit aus der aktuellen src-Version die entsprechenden RPMs zu erzeugen. Ich muss dann n icht bei jedem Release-/Versionswechsel nach dem passenden Regina-REXX-RPM suchen.


    Was ich noch nicht probiert habe, aus regina-rexx-3.9.7.tar.gz ein RPM zu bauen. Ich hab mir zwar von Mistral.ai mal eine Specs-Datei für Opensuse erstellen lassen, weiss aber noch nicht, ob das damit funktioniert.

    Ich müsste hier wahrscheinlich auch den configure-Propzess für Bauen der libregutil ergänzen. Ich hab da im Netz noch keine passende Doku für den Aufbau eines SPECS-File gefunden, mit dem ich was anfangen kann.


    Ich komme halt aus der IBM-Großrechnerwelt, und bin hier froh, wenn ich mein OpenSUSE mit meinem bisschen Linux-Wissen am laufen halte

    Zuerst mal ein frohes Osterfest an alle Forummitglieder.


    Ich hoffe es kann mir hier jemand einen Tipp zur richtigen Vorgehensweise geben.


    Ich möchte aus dem regina-rexx-3.9.7-1-src.rpm mit rpmbuild --rebuild die erforderlichen Regina-REXX-RPMs bauen, weil in allen bisher gefunden Regina-REXX-rpms das libregutil fehlt und in den StandrdRepos von Leap 16.0 Regina-Rexx nicht mehr vorhanden ist. Das Source-RPM habe von Regina Rexx Interpreter runtergeladen.


    Das bzw. die RPMs konnte ich testweise mit rpmbuild --rebuilt zwar erzeugen, aber es wurde ohne das libregutil gebaut.


    Ich hab daher mir das src.rpm mir ARK angesehen und festgestellt, dass bei dem darin enthaltene regina-rexx.specs in der ./configure Zeile der Parameter --with-regutil fehlt.


    Wie gehe ich da korrekterweise vor, um die configure-Zeile zu ergänzen?


    Ich hab zwar früher schon mal kleiner Übungen von C-Programmen kompiliert, aber noch nie ein RPM gebaut und bin an der Stelle Neuling.


    Ich will meine REXX-Scripte für Leap 16.0 nicht alle auf eine andere Scriptsprache umbauen, sondern lieber dann die Regina-REXX-RPMs unter Leap 16.0 so erzeugen, dass ich meine REXX-Scripte weiterverwenden kann.

    Myrlyn hat auch noch ein paar Funktionen mehr. Myrlyn unterstützt z. B. zypper dup, zypper patch und zypper up, was in der Software-Verwaltung von YAST2 nicht vorhanden ist.


    Wobei ich diese Myrlyn-Funktionen nicht benötige, da ich mir für regelmäßige Aufgaben grundsätzlich entsprechende Scripte baue und nutze.