Beiträge von Spaceloop

    In den vergangenen Wochen wurde an verschiedenen Macros im OBS gedreht, sodass nun zum ersten mal bitidentisch reproduzierbare Pakete in den Tumbleweed-Repos landen. Das bedeutet, dass bei gleichem Sourcecode, gleicher Bauumgebung und gleichen Bauanleitungen nun sicher auch immer die gleichen Pakete im Ergebnis dabei rauskommen.


    Unter anderem wird eine Korrumpierung des ganzen Prozesses dadurch erschwert bzw. fällt leichter auf. Insgesamt bedeutet dies einen noch definierteren Buildprozess und einen Sicherheitsgewinn für die Nutzer.


    vgl.

    openSUSE Factory enabled bit-by-bit reproducible builds
    In March, the configuration for building openSUSE Factory was changed to be bit-by-bit reproducible (except for the embedded signature). Following this, the ...
    news.opensuse.org


    History — reproducible-builds.org


    Soweit ich weiß, können das bisher nur ganz wenige Distributionen (NixOS?).

    Das hängt von der verwendeten Hardware ab. Ich hatte vor einiger Zeit Tumbleweed mal auf einem China-Tablet installiert, es war über Touch bedienbar.


    Es gibt auch unterschiedliche Grade der Nutzbaren Funktionalität. Bei manche Hardware geht nur Einfach-Touch und keine Multitouch-Gesten. Oder ein Zusatzstift für Notizen lässt sich gar nicht oder nur eingeschränkt nutzen. Hängt wie gesagt vom Einzelfall ab.


    Dann ist Touch in den verschiedenen Desktops unterschiedlich gut nutzbar implementiert. Einige Einfach-Desktops können gar nichts damit anfangen.

    Die meiner Meinung nach konsistenteste Touch-Bedienung hat Gnome.

    Habs jetzt geschafft.


    Habe mich an die Anleitung aus dem englischen Forum von 2014 gehalten. Allerdings habe ich in der Zeile in der rules-Datei grundsätzlich "Shift+2 Anführungszeichen" benutzt.


    /etc/udev/rules.d/68-vhba.rules

    Code
    # Datei für CDEMu Daemon
    #
    KERNEL=="vhba_ctl", NAME="%k", MODE="0666", OWNER="root", GROUP="users"

    /etc/modules-load.d/vhba.conf

    Code
    vhba

    Warum das jetzt so geklappt hat, und vorher nicht, weiss ich nicht. :S


    Es empfiehlt sich, gcdemu als GUI dazu zu installieren. Es stammt aus der GNOME-Ecke und nutzt GTK, läuft aber auch unter KDE.


    Damit kann man einfach per Maus ein paar CD-Hardware-Tweaks einstellen wie Bad Sector Emulation, Übertragungsratenemulation usw. Sobald das Image mit gcdemu geladen wird, poppt in KDE der gewohnte Hinweis "Datenträger und Geräte" - Optische Disk - einhängen usw. auf, d.h. KDE denkt, es handelt sich um eine echte CD/DVD.


    So wollte ich das haben. :)

    Ich wollte eigentlich kein Extra-Repo einbinden. Ich müsste die Prio des KDE-Repos runtersetzen, damit nicht alle KDE-Anwendungen über das KDE Repo aktualisiert werden? Wird dieses Repo über OBS erzeugt?


    Zudem scheint acetoneiso2 nach dem was Wikipedia schreibt, ja eher ein Iso-Viewer zu sein? Wenn es nur um das Anzeigen geht, komme ich aktuell auch schon in Dolphin über Aktionen --> ISO anzeigen "in" das ISO.

    (Leider funktioniert ein schneller Test mit

    Code
    mount "iso:/home/gk/Videos/jazzjackrabbit2.iso/ISO9660Joliet level 1/" /home/gk/mounttest

    nicht, vermutlich da es über Fuse läuft?)


    CDEmu scheint tiefer im System anzusetzen und das "glaubhaftere" virtuelle CD-Laufwerk bereitzustellen. Es kann wohl auch mit einigen einfachen "Lesefehlern" auf dem Medium umgehen.

    Hallo,

    ich wollte mal einige meiner alten DOS- und Windows 98-Spiele unter Playonlinunx oder WINE testen. Dazu habe ich unter Leap (noch 15.4) die CDEmu-Pakete installiert.


    Leider lässt sich CDEMu nicht starten.

    Zitat

    FEHLER: Fehler beim Verbunden zum CDEmu Daemon: g-io-error-quark: Error calling StartServiceByName for net.sf.cdemu.CDEmuDaemon: Timeout was reached (24)

    nach etwas Recherche habe ich dann den CDEmu-Daemon direkt aufgerufen.


    Nach weiterer Recherche bin ich auf einem Beitrag der Gentoo-Kollegen in deren Bugtracker gestoßen:


    680674 – app-cdr/cdemu - cdemu0: Kernel I/O: failed to open control device /dev/vhba_ctl: Permission denied!


    Code
    The udev rules needs to be changed to the following:
    
    KERNEL=="vhba_ctl", SUBSYSTEM=="misc", TAG+="uaccess", TAG+="udev-acl"
    
    TAG+="uaccess" is for logind while TAG+="udev-acl" is for ConsoleKit. Tested and working for me.
    Code
    Non logind/ConsoleKit systems can create /etc/udev/rules.d/69-vhba.rules with the following:
    
    KERNEL=="vhba_ctl", SUBSYSTEM=="misc", MODE="0660", GROUP="cdrom"
    
    and add their user to the cdrom group.


    Ich verstehe das so, dass man unter /etc/udev/rules.d eine Textdatei 69-vhba.rules anlegen muss.


    Kann man in der Datei dann die Zeile KERNEL=="vhba_ctl", SUBSYSTEM=="misc", MODE="0660", GROUP="cdrom" als Einzeiler übernehmen, oder muss das untereinander?


    Verwendet openSUSE logind/consolekit oder nicht? Welche der beiden Varianten sollte man versuchen bzw. gibt es noch andere openSUSE-Besonderheiten, die zu beachten sind?

    Auch bei einem Leap Upgrade werden die Fonts erhalten.


    Na prima. Unabhängig davon verstehe ich das Problem ohnehin nicht. Wenn man die eigenen Fonts übertragen will, dann kopiert man das Verzeichnis vorher auf einen USB-Stick, eine CD/DVD oder einfach in ein entsprechend angelegtes Unterverzeichnis im Home-Verzeichnis und kopiert das nach dem Update wieder zurück.

    Also was jetzt?


    Meine Frage rührt daher, dass ich in verschiedenen Quellen gelesen hatte, wie einfach es sei, im Linux-Desktop die Einstellungen von einer Installation auf die andere zu übertragen: einfach alle Konfigurationsdateien (in der Regel versteckt mit .punkt) im Home-Verzeichnis rüberkopieren. Bei der Schrifteninstallation ist mir aber nun aufgefallen, dass diese nicht unter Home installiert werden, sondern irgendwo im System. Und gerade bei einem Upgrade würde ich es nicht ausschließen wollen, dass dabei auch einmal größere Umbauten durchgeführt werden und sich Pfade ggf. ändern können.


    Genau wie bei den Hintergrundbildern in /usr/share/wallpapers sollte man also auch bei den Fonts etwas aufpasssen...

    Eine Immutable-Distribution kann durchaus ganz nett sein. Das Kernsystem kann sich angeblich im laufenden Betrieb updaten. Die Flatpaks stößt Discover oder GNOME Software an, sodass sich das ganze ähnlich wie beim Handy anfühlt.


    Allerdings hätte ich Yast schon ganz gern dabei!

    Danke muss ich testen. Es hat für mich auch eine gewisse Logik, da der Laptop so den Speicher in Swap kopieren kann - aber: kann er einzelne RAM-Module abschalten??


    Blöd und seltsam ist aber das "halbgare" Ergebnis mit einem Mauscursor auf ansonsten schwarzem Monitor.


    EDIT: hab mich gerade noch mal eingelesen. Ich glaube nicht, dass der Laptop in Suspend-to-disk ist (S4), sondern das Problem beim Aufwachen aus S3 oder S2 auftaucht. Es wird nach dem Aufwachen nichts von SSD geladen, aber das Login-Fenster erschien bei 15.4 nach ein paar Sekunden.

    Hallo,

    seit dem Update meines Laptops (altes Lenovo Thinkpad X60 mit Intel GMA 950-Grafik) auf Leap 15.5 und XFCE habe ich ein Problem mit dem Aufwachen aus dem Stromspar-Standby.


    -Nach längerem nicht-Benutzen: Laptop geht in den Stromsparmodus und schaltet Display ab

    -nach Berühren der Maus oder Tastendruck: Bildschirmbeleuchtung geht wieder an, Bildschirm bleibt aber schwarz. Es wird lediglich der Mauscursor dargestellt, der sich auch bewegen lässt. Der Anmeldedialog wird nicht angezeigt. Es funktioniert aber noch der Wechsel der Konsolen mit STRG+ALT+Fx... Bringt nur nix, wenn man Programme mit Daten in der F7 offen hatte. irgendwie fährt XFCE nicht mehr richtig hoch.