Beiträge von Horroreyes

    Dreamshader, bitte beschäftige dich nicht nur mit Einzelzitaten, dein ganzer Beitrag macht keinen Sinn. Debian-unstable ist KEINE Sammlung von unfertigen Programmen sondern eine nicht finale Zusammenstellung die irgendwann den stable-stand erreichen soll. Die Zusammenstellung, nicht die enthaltenen Programme.
    Dabei wird nach Debian-Manier darauf geachtet dass die enthaltene Software auch wirklich stabil läuft. Aber du vermischt (mal wieder) verschiedene Arten und Bedeutungen sowie Ebenen von unstable massiv und erzählst einfach nur Sch***!
    Ich kann du kein Beispiel für meine "Behauptung" nennen, denn bei jedem Beispiel wirst du aufgrund dessen, dass es nicht aufgenommen ist sagen, es sei instabil. Wie das funktioniert steht durchaus irgendwo in den Debian-Richtlinien. Die darfst du gerne selbst lesen, so viel Schwachsinn wie du dazu erzählst wäre das auch eine gute Idee.

    Dreamy, es ist wirklich Unsinn den du da erzählst. Auch Freigegebene Versionen werden nicht unbedingt als Paket aufgenommen, wenn es keine besonderen Gründe hat, denn jedes weitere aufgenommene Paket bedeutet mehr Pflegearbeit (Sicherheutsupdates, Bugfixes etc). Denn die alte Version (Wir reden ja von Major-Releases, da wird nicht ersetzt sondern hinzugefügt, daher die Versionsnummern in den Paketnamen) muss wegen Kompatiblitäten erhalten bleiben.

    Und ich kann mit Überzeugung sagen: Ein mit 4x übersetzter GCC ist genauso "richtig" wie ein mit 5.x übersetzter GCC. Die Geschwindigkeit kann besser sein, aber vermutlich nicht merkbar. Das spielt sich (wie bereits richtig von deets gesagt) in speziellen Ecken ab, die halt gerade für dein Sprachding praktisch sind.

    Was die Aussage angeht, dass Compiler auf Prinzip mit einer älteren Version gebaut werden müssen:
    Der erste Compiler muss natürlich sogar in einer anderen Sprache gechrieben werden, denn es gibt ja noch kein Programm in der neuen Sprache... auch keinen Compiler...
    Dieser erste Compiler kann auch sehr langsam sein und unsauberen Code generieren, Hauptsache der generierte Code ist korrekt.
    Wenn man dann einen Compiler in der neuen Sprache schreibt, dann macht man es "richtig". Also ein sauber entwickelter, schneller Compiler der auch guten Code erzeugt. Aber nicht richtiger, nur besser.
    Genauso kann man es natürlich auch mit der Version machen. Wenn die GCC-Leute eine super Verbesserung in ihren Compiler einbauen, der das kompilieren wesentlich verbessert, dann werden sie den neuen Compiler auch per zweitem Durchlauf mit sich selbst kompilieren um diese Vorteile zu nutzen.
    Aber wie gesagt: Das ist sehr wahrscheinlich ein minimaler Unterschied und zufällig in deinem Anwendungsfall gerade nötig.

    Harry, dann war der Pfad nicht richig bzw die Berechtigung falsch gesetzt, sorry aber das muss der Fall sein. Vor allem wenn du Unterschiedliche Fehler hinbekommen hast.
    Wenn du uns zeigst, wie du das versuchst, dann können wir dir dabei vielleicht helfen.

    @dreamy: Ein dist-upgrade hat NICHTS mit einem Distributionsupgrade zu tun, ein dist-upgrade upgradet auch Pakete wenn dadurch andere Pakete (die nicht manuell installiert wurden) verändert werden (Eine Abhängigkeit sich ändert, eine Inkompatibilität hinzukommt oder ähnliches). Den Namen verstehe ich auch nicht, aber die man-page ist überdeutlich, dist-upgrade hat nichts mit Distribution zu tun!

    @keith: Ich fragte WO du das upgrade gemacht hast (raspberry oder anderes System? Das sSystem über das wir gerade reden?
    Ich fragte WO die Ordner entstehen (Pfadangabe)
    War es vorher ein Raspbian wheezy? Oder was hattest du ursrünglich installiert?
    Hast du Änderungen in /etc/sources.list oder einer Datei in /etc/sources.list.d/ gemacht?

    Ich glaube dir ja, das du dir Mühe gibst... und das du nciht alle Fragen beantworten kannst, könnte ich auch noch nachvollziehen... das aber eine Antwort auf die ganzen Fragen passen soll, auch direkte Fragen wie "Hast du etwas verändert" (Ich nannte es rumgespielt) sollten schon irgendwie verständlich sein... Ich kann daher nicht wirklich glauben das du meinen Post richtig gelesen hast, sorry.

    rofl!
    Das einzige was ich nicht gefragt habe war "Wie hast du das Update installiert", aber das ist das einzige was du beantwortet hast...
    Dreamy: Heißt das Raspbian macht ein rolling release? Oder versteh ich dich falsch?

    Ja er verwendet bereits einen Konsolen-mysql-befehl, aber ich hatte gehofft, dass er mit dem Standard-Mysql und ohne weitere Optionen selbst feststelle, dass es wohl am Nutzer liegen muss.

    Autostart + Linux in Google oder der Forumssuche bringt mehrere tausend funktionierende Antworten... Ich helfe auch gerne beim finden der richtigen Suchbegriffe, aber diese Frage haben wir mit allen möglichen Formulierungen schon besprochen. Da muss man auch mal mit einem "Such selbst" leben können. Wenn es dann nicht klappt sind wir gerne wieder da. Für allroundservice ohne Selbstdenken muss man aber Geld in die Hand nehmen, das muss auch klar sein!

    Leute Leute... jetzt verratet dem armen Kerl doch einfach das einfache Problem und warum chmod + 777 (zufällig) hilft!

    Das Problem ist, dass das bash-script nicht ausführbar war. Mit ./script.sh (und auch mit vollem Pfad /wo/auch/immer/script.sh ) können nur ausführbare Deteien ausgeführt werden. Das ist auch sinnvoll, ansonsten könntest du ja Bilder ausführen oder sowas...
    Die Ausführbarkeit einer Datei ist im x-bit der Berechtigungen festgelegt, nochmal "auf Deutsch": Eine Datei ist ausführbar, wenn der aufrufende Benutzer die "Berechtigung" hat, die Datei auszuführen. Das geht mit "chmod +x <datei>".
    chmod ändert die Berechtigungen einer Date.
    Die Dateiberechtigung 777 heißt "jeder darf alles". Da du zu 'jeder' gehörst und die Ausführungsberechtigung Teil von 'alles' hat das geholfen, ist in diesem Kontext aber Schwachsinn!!!!!
    Dein Problem ist ein absolut typisches Anfängerproblem, hätte ziemlich jedem hier sofort klar sein müssen, hätte ich aber durchaus auch schnell ergooglen lassen mit etwas mitdenken.

    Es ist also nicht so, dass du mit sudo nicht alles darfst, sondern dass die Ausführbarkeit sinnvollerweise nicht durch sudo beeinflussbar ist (Denn auch ein Admin möchte keine Bilder ausführen :) )

    Ps. eine Alternative ist, die Datei nicht direkt auszuführen, sondern dem Interpreter zu übergeben:

    Code
    sh script.sh
    oder
    bash script.sh


    Die Endung muss auch nicht sh sein, das dient nur der Übersichtlichkeit, damit man weiß, wie man die Datei aufrufen kann, ohne reinzugucken.

    Versuch mal mit

    Code
    mysql -u log -p


    dich anzumelden. So wirst du nach dem Passwort gefragt, du brauchst es nicht direkt anzugeben. (In deinem Skript musst du das natürlich shcon machen, es sei denn du willst alle 5 min dein Passwort eingeben :P )

    Wenn du dort Dateien speichern kannst, dann kannst du doch opelssl oder was auch immer einfach drauf kopieren und nutzen, du musst das ja nicht "installieren". Installieren ist ja auch nur ein kopieren an eine Stelle von der aus es automatisch aufgerufen werden kann.

    Sorry, hast zum Teil Recht, ich muss dich verwechselt haben, und den Tag war ich tatsächlich ein bisschen gefrustet. Wollte nicht gleich darauf antworten als ich noch schlecht drauf war , habs dann später vergessen. Tut mir Leid.

    Naja, mit dem Paketsystem gibt es nahezu nie Probleme, man kann einfach eine Liste der Pakete irgendwo speichern und dann als Liste so installieren, dann ist der Stand wieder hergestellt, extra Sichern muss man dann nur alles unter /home (Persöhnliche Daten) und die angepassten Einstellungs-dateien (liegen meistens irgendwo unter /etc ) und gegebenenfalls noch /var/www wenn man einen Webserver hat (einige andere Programme haben auch noch Daten irgendwo in /var aber das wei0 man dann hoffentlich selbst, wenn man die nutzt.

    Das mysql-Paket hat mir auch schon Schwierigkeiten gemacht, sobald man es vergeigt das Passwort beim ersten mal korrekt zu setzen (vermutlich wegen fehlendem Speicherplatz bei dir) zickt das ungewöhnlich rum... Gerade Speicherplatzprobleme können ätzend sein, weil der Vorgang an völlig ungeplanten Stellen hart gestoppt wird.

    Es ist völlig egal ob zu zuerst nur ein paar der Pakete installierst und dann den Rest hinterher, wenn da Abhängigkeiten drinn sind, dann werden die Automatisch mitinstalliert und danach auch kein zweites Mal installiert. Das ist also nicht der Grund für dein Problem.
    Trotzdem kann es sinnvoll sein Pakete komplett inklusive Einstellungen zu entfernen, das ist natürlich richtig. Das gibt es auch: apt-get purge <paketname(n)>
    Insgesamt ist dir jedoch vermutlich mehr geholfen, wenn du uns den Fehler verrätst den du bekommen hast, denn wie gesagt: Die Pakete einzeln zu installieren kann (außer bei fehlerhaft erstellten Paketen von denen wir hier wohl nicht reden) nicht der Grund sein.

    Naja, das ist eine Bibliothek. Da kommt keine ausführbare Datei raus (außer möglicherweise Tests wie hier der Fall) Bibliotheken muss man verwenden. Das kannst du nun damit tun. In den Tests kann man oftmals Beispiele finden, wie man es verwende kann.

    Gibt es ein Tool um das ganze zu automatisieren? *g* Das sind schon Tools dafür.
    make ist ein Tool um die Compileraufrufe zu automatisieren, ansonsten müsstest du ersu compilieren mittels gcc (oder ähnlichem), dann linken. Und das nur in einem einfachen Fall, da kann noch wesentlich mehrkommen.
    cmake ist ein Tool um das make-file,also die Anweisungen für make automatisch auf Grundlage der tatsächlichen Situation inklusive Abhängigkeiten etc. erstellt. Ansonsten würdest du das alles manuell eintragen müssen. (Eine bekannte Alternative zu cmake ist "autotools" die man mit ./configure aufruft).
    Was du natürlich machen kannst ist, ein shellscript zu erstellen:

    Bash
    #!/bin/sh
    mkdir build
    cd build
    cmake .
    make
    cd ..

    Ungetestet!!! Nur mal so runtergeschrieben. Mal einen build-Ordner hinzugefügt um mehr Ordnung zu schaffen, wenn das schon automatisch passieren soll ist Ordnung immer gut.

    Das git-Zeug zu automatisieren macht wenig Sinn, denn du hast den Code ja schon... das musst du nur das eine Mal machen.
    Jedoch macht auch das automatische bauen wenig Sinn, denn auch das musst du nur das eine Mal machen... es ist halt eine Bibliothek... wenn die gebaut ist, dann ist die fertig. Das Script dient also mehr akademischen Zwecken. :)

    Dann hast du vermutlich cmake falsch ausgeführt. Lösche das Repo nochmal (damit wir definitiv vom selben Stand ausgehen und nicht noch irgendetwas herumfliegt)
    Dann clone das repo: git clone https://github.com/answer17/lidarLite.git
    Dann gehe in das Verzeichnis: cd lidarLite
    Dann rufe cmake auf: cmake . # ja mit --> . <--
    dann rufe make auf: make
    Fertig.

    Das hat übrigens GARNICHTS mit github zu tun, das ist einfach ein CMake-Projekt.Es ist jedoch allgemein sinnvoll und daher üblich header (lib) und Quellcode (src) zu trennen.
    Aber garnichts an deiner Frage hat irgendetwas mit github zu tun.