Beiträge von Spaceloop

  • Bericht: pyenv - Umschalten zwischen verschiedenen (auch neuen) Python-Versionen unter Leap

    Hallo,


    ich bin mir nicht sicher, wo ich den Beitrag am besten posten soll. Unter Leap hatte ich in den letzten Monaten gelegentlich das Problem, dass ich Python-Programme testen wollte, aber die Python-Version von Leap zu alt war. Ich habe dann herausgefunden, dass es mit pyenv ein Tool gibt, womit man verschiedene Python-Versionen auf dem System einrichten und zwischen ihnen frei wechseln kann.


    Ich bin so vorgegangen,

    1. dass ich pyenv zunächst über die Softwareverwaltung/Zypper installiert habe. Irgendwas ging dabei nicht richtig. Ich habe dann das Verzeichnis ~/.pyenv gelöscht und bin nach der manuellen Installationsanleitung auf https://github.com/pyenv/pyenv#installation vorgegangen:


    Code
    git clone https://github.com/pyenv/pyenv.git ~/.pyenv

    (... wobei ich da wieder ein http/https-Problem hatte und es am Ende mit http funktioniert hat)


    Code
    cd ~/.pyenv && src/configure && make -C src



    2. um später Python-Umgebungen einzurichten, müssen leider noch weitere Pakete in zypper nachinstalliert werden. Hier wurden leider keine Abhängigkeiten definiert. Bei mir war es:

    -libopenssl-*-devel (passend zur installierten libopenssl - ohne bricht später die Installation anderer Versionen ab)

    -sqlite3 und sqlite3-devel (ohne gibt es später eine Warnung)

    -python-tk

    -tk-devel

    -tcl-devel

    -python3-virtualenv


    (weitere Abhängigkeiten sind laut der Projektseite

    Code
    zypper install gcc automake bzip2 libbz2-devel xz xz-devel openssl-devel ncurses-devel \
readline-devel zlib-devel tk-devel libffi-devel sqlite3-devel gdbm-devel make findutils patch

    aber anscheinend war davon schon einiges bei mir installiert oder kam mit dem pyenv-Paket...)



    3. anschließend muss ~/.bashrc und ~/.profile ergänzt werden:


    Code
    echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc

echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.profile
echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.profile
echo 'eval "$(pyenv init -)"' >> ~/.profile


    Ich hoffe, dass ich nichts vergessen habe...


    Code
    exec "$SHELL"

    liest die geänderte bash-Konfiguration neu ein.


    II. Benutzung:


    1.

    Code
    pyenv versions

    Listet installierte Umgebungen


    2.

    Code
    pyenv version

    listet aktuell von pyenv aktivierte Python-Version


    3.

    Code
    python --version

    der endgültige Test: welche Version liefert die Python-Umgebung zurück?


    4.

    Code
    pyenv install 3.9.1

    installiert die Umgebung Python 3.9.1


    5.

    Code
    pyenv local 3.9.1
pyenv global 3.9.1

    aktiviert Version 3.9.1 als lokale / globale Umgebung. Den genauen Unterschied habe ich noch nicht verstanden. Mir scheint bisher local für meine Zwecke zu reichen. :/ Überprüfung mit pyenv versions (Markierung durch Stern) oder python --version.


    6.

    Code
    pyenv init

    soll die Shell-Anmeldung anstelle der obigen manuellen .bashrc erledigen, habe ich aber noch nicht getestet.


    Jedenfalls finde ich das Tool sehr nützlich. :) Man kann sich beliebige Python-Umgebungen ziehen und das System zwischen ihnen umschalten. Gerade bei Leap ist Python ja immer ein gewisses Thema... Ich muss mich aber noch genauer damit befassen, was es mit local/global und virtuellen Python-Umgebungen auf sich hat. Interessant ist auch, dass nach einem Distributionsupgrade von Leap 15.4 auf 15.5 die Shell-Einbindung weg war. Heisst das, zypper dup überschreibt .bashrc und .profile der User?


    Plugins:

    pyenv unterstützt Plugins, welche auf der Projektseite angeboten werden. Sie werden in .pyenv/plugins in Unterverzeichnissen installiert. Ich habe sie einfach über die git clone-Aufrufe auf den jeweiligen Plugin-Webseiten des pyenv-Projekts auf github installiert, also z.B.


    Code
    git clone https://github.com/pyenv/pyenv-update.git $(pyenv root)/plugins/pyenv-update

  • Chuwi Hi10x Soundkarte Everest ES8336 konfigurieren - modprobe.d und Tumbleweed

    Das kommt aus der Zeit, als die Unterstützung für den Chip mit Linux 5.18 ff. Fahrt aufnahm. Ich war ungeduldig und wollte jeden RC mitnehmen.


    Was mir auch noch aufgefallen ist: bei jedem bisherigen Kernelupdate kommt eine Fehlermeldung zu /etc/modprobe.d/alsa-base.conf, weil das erste Wort "opitions" sei. Ganz am Anfang hatte ich da tatsächlich diesen Tippfehler drin, aber der ist mittlerweile seit Ewigkeiten korrigiert. Trotzdem kommt immer eine derartige Meldung.


    Bisher habe ich angenommen, dass alsa-base.conf bei jedem Neustart neu gelesen wird. Oder gibt es da irgendwo eine Art versteckten Cache?

  • Chuwi Hi10x Soundkarte Everest ES8336 konfigurieren - modprobe.d und Tumbleweed

    Hallo,

    ich habe hier ein Chuwi Hi10x-Tablet. Der verbaute Soundchip Everest ES8336 gilt unter Linux als schwierig und lässt sich nicht automatisch konfigurieren. Lange war die Unterstützung in Linux fraglich. Inzwischen lässt sich dem Tablet unter Linux allerdings Sound entlocken.


    Allerdings: ich muss nach jedem Neustart manuell im Pulseaudio Lautstärkeregler den Tonausgang von "Headphones (eingesteckt)" auf "Speakers (ausgesteckt)" umstellen. D.h. offenbar ist die Erkennung des Einsteckens irgendwie vertauscht.


    Hier gibt es eine Anleitung vom sofproject:

    Suggestions before filing an SOF bug — SOF Project 2.5.0 documentation


    Ich habe also wie beschrieben eine Datei /etc/modprobe.d/alsa-base.conf angelegt mit der Zeile

    Code
    options snd_soc_sof_es8336 quirk=<value>

    Bei Value habe ich inzwischen 0x10, 0x20 und 0x30 durchprobiert und jeweils danach neu gestartet. Allerdings hat sich am Ergebnis nichts geändert. Ich habe inzwischen auch Zweifel, ob das System diese Einstellungen überhaupt richtig verarbeitet.


    Zitat

    The default quirk value for the platform can be read from /sys/module/snd_soc_sof_es8336/parameters/quirk (the value is reported as plain integer, not hexadecimal).

    Code
    cat /sys/module/snd_soc_sof_es8336/parameters/quirk

    liefert stoisch -1, egal was ich bei Value einsetze. Das klingt für mich nach einem illegalen oder nicht definiertem Wert. Außerdem hätte ich damit gerechnet, dass alsa-base oder snd_soc_sof_es8336 (oder irgendsoetwas) bei lsmod auftauchen müsste. Das ist aber nicht der Fall.


    Ich habe das Gefühl, dass ich hier noch eine Lücke bzgl. Kernelmodule habe... :/

  • openSUSE stellt "Slowroll"-Variante vor

    Zitat von Karlchen60

    moin Alero,

    blicke da langsam nicht mehr durch...

    heißt das jetzt, das Alp bzw,. MicroOS wieder eingestampft wird ?


    Zitat von Alero

    Wieso? Die haben gemerkt, dass das ALP oder wie auch immer starke Ablehnung erfährt und dass das alles nicht so umsetzbar ist, wie sie dachten ... also stampfen wir was Neues aus dem Boden. Ich bin gespannt. Werde es nun installieren. Vielleicht lege ich im Forum auch noch eine Rubrik "Slowroll" an.



    Wie ich das verstehe, gibt es MicroOS auch weiterhin. Allerdings lässt sich ein grafischer Desktop darauf nur schwer realisieren, oder ein komfortables Softwaremanagement. Für einen Server, der nur über die Kommandozeile bedient wird, hat man aber mit MicroOS eine gute Möglichkeit, Container laufen zu lassen, mit unveränderlichem Basis-OS und was es an aktuellen Konzepten noch so gibt.

  • openSUSE stellt "Slowroll"-Variante vor

    Bisher gab es Leap und Tumbleweed. openSUSE stellt nun openSUSE "Slowroll" vor, ein auf mehr Stabilität getrimmtes, langsameres Tumbleweed. Damit gibt es nun drei Varianten. Der Hintergrund ist offenbar, dass sich das SLED nachfolgende, containerbasierte ALP-Produkt nur sehr schwierig auf Desktop-Nutzung trimmen lässt. Somit hätte ein ALP-Leap-Nachfolger in absehbarer Zeit keinen vernünftigen Desktop. Insbesondere das modulare KDE soll sich nur sehr schwer in Container packen können.


    Somit wird Slowroll wohl der vorgesehene Migrationspfad für Leap-User nach der 15.6. :/


    Aber seht selbst:


    Reports - OpenOS

    openSUSE:Slowroll - openSUSE Wiki

    openSUSE Wants to Replace Leap With a New Offering
    openSUSE Leap is set to be replaced with a new option. Learn more about it here.
    news.itsfoss.com

  • Software aktualisieren oder nicht?

    1) NVidia-Treiberprobleme waren in den letzten Jahren selten


    2) Wenn das System nicht richtig hochfahren will: 1. Vorigen Snapshot beim Start in GRUB auswählen 2. Terminal öffnen 3. "sudo snapper rollback" sowie Root-Passwort eingeben (4. ggf. Update in einer Woche nochmal probieren)



    Mehr muss man eigentlich nicht wissen.

  • Leap: eSATA-Platte unter KDE dauerhaft sicher entfernen

    Hallo,

    bei meiner Backup-Lösung habe ich noch ein kleines Problem mit dem externen eSATA-Gehäuse (Mercury Elite Pro):


    Ich bekomme es in KDE rechts in der Tray-Leiste unter "Datenträger und Geräte" nicht hin, das Gerät dauerhaft zu entfernen. Es wird zwar als Wechseldatenträger angezeigt, aber wenn man es entfernen will, wird es nach einer halben Sekunde wieder erneut verbunden und erscheint als angehängtes Gerät. Der eSATA-Anschluss ist ein Slotblech mit eSATA-Anschluss und internem Stecker für das Mainboard. Den Port auf dem Mainboard habe ich im BIOS auch als eSATA konfiguriert.


    Abgesehen davon läuft alles bestens.

  • Fragen und Überlegungen zu Backup-Strategien eines Desktops

    Hab jetzt einfach mal btrfs installiert, da es a) auch Checksummen implementiert hat und b) quasi das Standarddateisystem von openSUSE ist. Das bedeutet aber auch, dass die Windows-NTFS-Nutzerdaten aus Linux heraus mitgesichert werden müssen, zumindest wenn man direkt kopieren will. Glücklicherweise ist das System aus der Zeit teurer SSDs und billiger Platten, sodass Programme auf der SSD und Daten auf der Platte ziemlich sauber getrennt sind.


    Zum Direktkopieren der jeweiligen Datenverzeichnisse auf die externe btrfs-Platte musste ich mich allerdings als root anmelden - irgendwie logisch, aber auch elegant??


    Kopiert habe ich aus Dolphin raus, damit die Sicherung erstmal erstellt ist. Ich brauche aber noch eine Dauerlösung und denke, dass irgendetwas auf rsync-Basis vermutlich das beste für meine Zwecke ist.

  • Software aktualisieren oder nicht?

    Die Vorteile bei openSUSE:


    1) Wenn man Leap oder Tumbleweed mit btrfs-Dateisystem installiert hat, könnte man im Falle eines Problems auch in den vorigen System-Snaphot booten. Der wird beim Update automatisch gesichert. Ich habe das aber bisher erst einmal gebraucht, und zwar auf einem uralten System mit exotischer Konfiguration, was auch sonst schon diverse Ausfallerscheinungen zeigte...


    2) Ich schätze an openSUSE genau die Tatsache, dass Updates einfach so funzen wie sie sollen. :) Was auch an einem umfangreichen automatisiertem Testen der Update-Pakete liegt. Stichwort: http://open.qa/


    Das sind zwei Dinge, die du einfach mitnimmst, wenn du openSUSE mit Standardeinstellungen installierst. Bei den meisten anderen Distributionen ist gar nichts davon implementiert oder muss umständlich manuell nachgerüstet werden. Das heißt, die Gefahr, dass du mit einem einzigen Update das bis dahin super laufende System in einen Zustand versetzt, wo du es komplett neu aufsetzen musst, ist bei openSUSE faktisch nicht vorhanden! Eher sind nicht behobene Sicherheitslücken problematisch, wenn man nicht aktualisiert. Vor allem, wenn der Browser (Firefox) auf dem Versionsstand der Installation über die Zeit verschimmelt... Browser, E-Mail-Clients, aber auch die SSL-Bibliotheken sollten immer aktuell sein.