GNU/Linux Debian 11 »Bullseye« Release-Datum steht

Debian Swirl

Bereits seit einigen Monaten gab es mit dem 31. Juli ein voraussichtliches Datum für die Veröffentlichung von Debian 11 »Bullseye«. Nachdem am vergangenen Wochenende mit dem »Full Freeze« die letzte Stufe der Entwicklung zu Debian 11 eingeleitet worden war, haben die Entwickler nun das Datum für die Veröffentlichung auf den 14. August festgelegt. Wie es bei Debian Tradition ist, stammt der Codename wieder aus dem Hollywood-Streifen Toy Story. Bullseye ist in Toy Story 2 das Pferd von Sheriff Woody.

Neun Architekturen

Damit erscheint Debian 11 als 15. offizielles Release der Distribution rund 25 Monate nach Debian 10 »Buster« und bleibt damit im üblichen Rahmen von zwei Jahren. Am längsten hatte 2005 die Veröffentlichung von Debian Sarge gedauert, die 2,8 Jahre brauchte. Das neue stabile Release von Debian wird in neun Architekturen mit dem aktuellen LTS-Kernel 5.10 ausgeliefert. Die Veröffentlichung enthält über 13.370 neue Pakete, was zu einer Gesamtanzahl von 57.703 Paketen führt. Über 35.530 Software-Pakete der Distribution wurde aktualisiert. Außerdem wurden 7.278 Pakete aus verschiedenen Gründen aus der Distribution entfernt.

GNOME weiterhin Standard

Bei den Desktop-Umgebungen wird Debian 11 unter anderem mit GNOME 3.38, KDE Plasma 5.20, LXDE 11, LXQt 0.16, MATE 1.24 und Xfce 4.16 ausgeliefert. Bei den Office-Paketen wurde LibreOffice auf 7.0 aktualisiert, während Calligra in Version 3.2 ausgeliefert wird. Weitere aktualisierte Pakete sind GCC 10.2, LLVM/Clang 9.0.1 und 11.0.1, Apache 2.4.46, Nginx 1.18, MariaDB 10.5, PHP 7.4, Perl 5.32, OpenSSH 8.4p1, OpenJDK 11, Python 3.9.1, Samba 4.13, Vim 8.2, Gimp 2.10.22 und Inkscape 1.0.2.

Drucken ohne Treiber

Es gibt zudem einige Neuerungen wie etwa das Drucken ohne Treiber über das Paket ipp-usb. Das ist ein Userspace-Treiber für USB-Geräte (Drucker, Scanner, MFC), der das Protokoll IPP-über-USB unterstützt und bei OpenPrinting entwickelt wurde. Dadurch können diese USB-Geräte als normale Netzwerkdrucker angesehen werden. Bei Systemd ist persistentes Logging per Journald erstmals standardmäßig aktiviert.

Bei den Debian-Paketen für Firefox und Chromium wird DuckDuckGo als Standard-Suchmaschine voreingestellt sein. Das Linux Terminal Server Project (LSTP) wurde völlig neu geschrieben. Natürlich bringt Debian 11 auch ein neues Theme für die visuelle Gestaltung mit, dass auf den Namen Homeworld hört.

Wer bereits jetzt einen Blick auf Debian 11 werfen möchte, kann dies mit dem im Juni veröffentlichten Debian Installer Bullseye RC 2 tun. Wer bereits Debian installiert hat, kann mit der Umstellung der Quellenliste auf testing bereits jetzt zu »Bullseye« wechseln.

Kommentare

40 Antworten zu „GNU/Linux Debian 11 »Bullseye« Release-Datum steht“

  1. Avatar von Graf Zahl
    Graf Zahl

    Kann mir jemand vielleicht kurz erläutern wie die Auswahl der Pakete zustande kommt?

    z.B. Plasma. Hier legt ja der Preining ordentlich Tempo vor, die letzte Version die er bauen konnte vor dem freeze war also 5.20? Während die letzte LTS aber 5.18 ist. Das LTS von KDE hat hier bezüglich „stable“ keine Relevanz?

    Das gleiche bei z.B. MariaDB, da ist es auch einfach die letzte Version die vor dem freeze verfügbar war und keine „Schwierigkeiten“ beinhaltet?

    Gnome. Hier ist den Debian-Entwicklern die 40er wohl noch nicht ganz geheuer und deshalb nehmen sie dann lieber eine 3.38er, bevor sie in unbekannten/unsicherem Gewässer für die nächsten zwei Jahre gefangen sind?

    Lerne ich daraus, dass

    1. die letzte Version genommen wird, die es vor dem freeze in „Testing“? gab, außer es gibt vielleicht einen guten Grund doch eine andere Version als die letzte zu nehmen wie bei Gnome?
    2. sich „stable“ gar nicht so sehr auf eine stabile (wenn möglich LTS) Version einer Software bezieht, sondern eher auf das möglichste stabile „Umfeld“ an Paketen einer Veröffentlichung? Also das Softwareentwickler die jetzt Pakete für Bullseye schnüren sich immer sicher sein können, dass diese oder jene Paketversionen vorhanden sind, welche im Lebenzyklus dieser Veröffentlichung nur auf Minor/Patch-Level aktualisiert werden?

    Oder liege ich da falsch, bzw. wie verhält sich das tatsächlich? Danke.

    1. Avatar von Ferdinand

      Plasma 5.18 LTS ist vom Februar 2020, wäre also ab 2/2022 auch nicht mehr mit Support versorgt. Plasma 5.20 ist von Mitte Oktober 2020. Der Zeitraum für Plasma 5.21 war zu knapp, also blieb es bei 5.20. Wenn Preining hier nicht Initiative gezeigt hätte, wäre es wohl 5.18 LTS geworden. Generell kann man hier keine Regel aufstellen, es obliegt den Entwicklern/Maintainern der Pakete und dem Release-Team, was ins Release kommt. Es kommt schon auf Stabilität an, die bestmöglich verifiziert wird, bevor die Pakete nach Sid hochgeladen werde. Dann durchlaufen sie auch noch den Testing-Zweig und können deshalb schon als gut getestet betrachtet werden. Es zählt sowohl die Stabilität der einzelnen Pakete als auch deren Auswirkungen auf die Gesamtstabilität. Software-Entwickler, die jetzt Pakete für Bullseye schnüren haben das Nachsehen. Im Full Freeze werden nur noch wichtige Änderungen an bereits bestehenden Paketen hereingelassen. Und das nur auf Antrag.

      1. Avatar von Graf Zahl
        Graf Zahl

        Plasma 5.18 LTS ist vom Februar 2020, wäre also ab 2/2022 auch nicht mehr mit Support versorgt. Plasma 5.20 ist von Mitte Oktober 2020. Der Zeitraum für Plasma 5.21 war zu knapp, also blieb es bei 5.20. Wenn Preining hier nicht Initiative gezeigt hätte, wäre es wohl 5.18 LTS geworden.

        Schon mehrfach irgendwo aufgeschnappt habe ich Aussagen im Sinne von „Die Releasepolitik von KDE hat’s versemmelt“. Bezogen sich derlei Aussagen auf diesen Umstand? Also nicht jetzt nur für das aktuelle Geschehen, sondern es müssen Ereignisse aus der Vergangenheit gewesen sein.

        1. Avatar von Gerrit

          Im Grunde genommen ist das aus Sicht von Debian auch egal. Die Produktpflege der KDE Entwickler für die Plasma LTS hält sich in enorm engen Grenzen. Schau dir dazu einfach mal die Changelogs der paar Releases an. Das ist wenig mehr als ein Label, damit KDE behaupten kann, sie machen was für die Distributionen.

          Und anders als bei GNOME mit dem Wechsel auf 40 ist es bei KDE im aktuellen Zyklus egal ob 5.20, 5.21 ode 5.22. Bis zum Wechsel auf Qt6 ist hier vieles im Maintenance-Modus.

          1. Avatar von Bert
            Bert

             5.18.0-5.18.1/ 2021-07-07 14:05 –  

             5.18.1-5.18.2/ 2021-07-07 14:05 –  

             5.18.2-5.18.3/ 2021-07-07 14:05 –  

             5.18.3-5.18.4/ 2021-07-07 14:05 –  

             5.18.4-5.18.5/ 2021-07-08 21:09 –  

             5.18.5-5.18.6/ 2021-07-08 21:09 –  

             5.18.5-5.18.90/ 2021-07-07 14:05 –  

             5.18.5-5.19.0/ 2021-07-08 21:09 –  

             5.18.6-5.18.7/ 2021-07-07 14:05

            Ich sehe da kein „Produktpflege der KDE Entwickler für die Plasma LTS hält sich in enorm engen Grenzen„?

          2. Avatar von Gerrit

            Ich drösel das mal für dich auf:

            KDE 5.18.7 kam am 30. März 2021, 5.18.6 am 29.09.2020 = Alle halbe Jahr mal eine kleine Veröffentlichung? Alles davor gehört nicht zu LTS, weil alle Plasma-Versionen 5 Bugfix-Updates bekommen (kann man hier nachschauen). Wenn die Frequenz so weitergeht erleben wir bis zum EoL noch ein oder maximal zwei weitere Bugfix-Releases. Wenn überhaupt…

            Und dann schaue dir bitte die beiden Changelogs von 5.18.7 und 5.18.6 an. Die Fixes sind sicher nett und viel besser als gar nichts, aber rückportiert werden scheinbar oft kleinere Sachen, die sich schnell Cherry-picken lassen. Produktpflege mit intensiver Arbeit an einer LTS und vielleicht sogar einem zuständigen „Produktmanager“ ist das nicht.

            Zu guter Letzt ist noch zu berücksichtigen, dass Debian nach dem Release sowieso sehr zurückhaltend mit Updates ist. Was in den Changelogs ist so schwerwiegend, dass Debian es rückportieren würde? Die Update-Version würden sie ja sowieso nicht einspielen.

            Bei Sicherheitsupdates gäbe es sowieso einen separaten Fix, weil man ja nicht bis zu 6 Monate warten will.

            Unter den Gesichtspunkten kann ich gut verstehen, wenn Distributionen sich nicht an den Plasma LTS orientieren, sondern diese nur berücksichtigen, wenn sie gut in den Plan passen. Die große Masse der KDE-Software ist eh in KDE Gear und bekommt gar kein LTS.

            Ich hoffe das waren jetzt nicht zu vielen Fakten…

          3. Avatar von Andre
            Andre

            „Zu guter Letzt ist noch zu berücksichtigen, dass Debian nach dem Release sowieso sehr zurückhaltend mit Updates ist.“

            Debian interessiert mich persönlich überhaupt nicht.

          4. Avatar von Gerrit

            Schön für dich. Der Blogpost oben dreht sich aber um Debian. Hast du gemerkt oder?

  2. Avatar von Graf Zahl
    Graf Zahl

    Ferdinand, gestern habe ich realisiert, dass siduction eine Distribution ist bei der Du mitmachst und auf der Site gelesen, dass Ihr (jetzt gelöste, was mich beim lesen sehr gefreut hat) Probleme mit Eurem Buildserver hattet.

    Der Preining benutzt den OBS als Buildserver für Debian/Plasma und auch sonst findet man jede Menge Pakete auf dem OBS die auch für andere Distributionen sind. Er ist ja grundsätlich und wenn ich richtig verstanden haben ja ausdrücklich für alle Distributionen offen. Wäre das keine Lösung auch für siduction gewesen? Warum nicht?

    1. Avatar von Ferdinand

      Theoretisch wäre das vermutlich gegangen. Da wir aber z. B. immer viele aktuelle Kernel bauen und veröffentlichen, brauchen wir einen potenten Build-Server, den wir jetzt haben. Zudem bauen Debian-Entwickler etwa die PIM-Pakete auf unserem Server, was wegen Ressourcen vermutlich zusätzlich gegen OBS sprechen würde. Wir hatten OBS erst mal nicht in Betracht gezogen, sondern uns um eine eigene Lösung bemüht.

      1. Avatar von Graf Zahl
        Graf Zahl

        Das Debian auch bei Euch baut, habe ich Deinem Post auch gelesen und hatte/habe kein gutes Gefühl deswegen. Das liest sich ein bisschen wie „prekäre Situation“.

        Ich will jetzt nicht drauf rumreiten, aber wenn doch der OBS offen und für Euch ein sicherer Hafen sein könnte, weil nicht von einen Sponsor abhängig, ist es da nicht egal, ob die Maschine jetzt zwei oder drei Tage rödeln muss?

        Nachtrag: mmh, ich hab’s mir überlegt, mit dem OBS sind die dort genannten Firmen dann eben der Sponsor. Dann ist ein „eigener“ Sponsor für die Unahbhänigkeit vielleicht doch OK.

        1. Avatar von Ferdinand

          Das liest sich ein bisschen wie “prekäre Situation”. Wo siehst Du da eine prekäre Situation?

          1. Avatar von Graf Zahl
            Graf Zahl

            Das es unsicher ist, wo die Hardware herkommen soll auf der die Pakete gebaut werden.

            In ungefähr so: Wenn Ihr nicht den Sponsor aufgerissen hättet, hättet das ganze Debian und Siduction keine Möglichkeit gehabt, wichtige Pakete für die Veröffentlichung einer nächsten Version zu bauen. Das Wohl und Wehe einer ganzen Distribution hängt daran, ob sich ein Sponsor für die Buildserver findet.

            Bauen nicht auch viele Unternehmen auf Debian? Und da kommt nicht mal soviel zurück, dass das Projekt eine stabile/sichere Infrastrukur finanzieren kann?

            Also bevor ich da losheulen muss, was genau verstehe ich nicht oder ist mir unbekannt?

            Oder aber es ist vermutlich genau die (gewünschte?) Realität, welche ein nicht kommerzielles (Community) Vorhaben ausmacht und eine mir bisher unbekannte Normalität repäsentiert.

          2. Avatar von Ferdinand

            Im unwahrscheinlichen Fall, dass sich trotzt unserer guten Kontakte kein Sponsor gefunden hätte, hätten wir einen entsprechenden Server gemietet.

          3. Avatar von Graf Zahl
            Graf Zahl

            Und die Kohle dafür kommt dann auch der Gemeinschaft derer die sich sowieso schon immer engagiert haben, während (Achtung Unterstellung) die „blinden“ Nutznießer sich einfach freuen, dass es wieder eine neue Version gibt, aber an der ein oder anderen Stelle doch ein bisschen kritisieren, dass dies oder jenes nicht nach den eigenen Vorstellungen läuft.

            OK. Vielen Dank mal für die Auskunft bisher. Ich muss darüber nachdenken.

            Schönen Tag noch.

          4. Avatar von Graf Zahl
            Graf Zahl

            z.B. Hetzer

            https://docs.hetzner.com/de/konsoleh/general/faq/softwareupdate2019/

            Upgrade Stretch > Buster

            Könnte der nicht mit Leichtigkeit _seiner_ Distribution aus reinem Eigeninteresse alles zur Verfügung stellen was benötig wird?

          5. Avatar von Ferdinand

            Hetzner unterstützt Projekte meines Wissens nur mit Hardware, die in irgendeiner Form, z.b. als e.V. organisiert sind.

          6. Avatar von juchtel
            juchtel

            Was mit Sicherheit steuerliche Gründe hat; weil nur e.V.s, die als gemeinnützig anerkannt sind, können Quittungen für Spenden ausstellen; andernfalls wäre die besagte Hardware nämlich weiterhin Betriebsvermögen von ( in diesem Falle) Hetzner, und müßte jährlich besteuert werden…..

          7. Avatar von Graf Zahl
            Graf Zahl

            Also bevor ich da losheulen muss,

            Ah!!!! Moment, eben hat es geklingelt! Es ist die Freiheit, stupid!

  3. Avatar von Fraggle
    Fraggle

    Wer bereits Debian installiert hat, kann mit der Umstellung der Quellenliste auf testing bereits jetzt zu »Bullseye« wechseln.

    Besser „bullseye“ als „testing“ dort eintragen, sonst folgt man nach dem Release ja gleich der nächsten in Entwicklung befindlichen Version. Außerdem sollte man die Hinweise in den Release Notes bezüglich der geänderten Syntax der Paketquelle für security.debian.org beachten.

    1. Avatar von Ferdinand

      Danke, das mit der geänderten Syntax bzgl. security.debian.org ist mir bisher entgangen.

  4. Avatar von tuxnix
    tuxnix

    Ich denke, dass der Begriff „stable“ zu Fehlinterpretationen führt.
    Ein Programm wird nicht dadurch besser, „stabiler“ oder weniger fehlerbehaftet in dem man es 2 Jahre lang ablagert. Die Stabilität um die es hier geht, bezieht sich denn auch nicht so sehr auf das einzelne Programm, sondern auf die Gesamtkonstruktion die nach dem Einfrieren auf einem fixen Versionsstand der Einzelkomponenten in einem „starren“ Zustand verharrt.

    Dieses Missverständnis wird um so mehr davon geschürt, als das die beiden rollenden Ausgaben von Debian den Namen „unstable“ und „testing“ tragen.

    Man sollte m.M.n. hier eine Umbenennung vornehmen.

    unstable -> rolling
    testing -> tested
    stable -> static

    Allein schon diese Umbenennung würde Debian neue User zuspielen und den Fokus der Distribution dann auch ein wenig mehr auf den ständigen Erneuerungsprozess von Software lenken.
    Stabilität durch Einfrieren ist nur in den Bereichen von hoher Wichtigkeit, wo man auf ein starres Fundament für seine eigenen Aufbauten angewiesen ist.
    Jedenfalls finde ich es schade, dass allein durch die etwas unglückliche Namensgebung Desktop-User oft davon abgeschreckt werden zu ’sid‘ zu greifen, weil sie es fälschlicher Weise für „instabil“ halten.

    1. Avatar von Graf Zahl
      Graf Zahl

      Danke, sehr einleuchtend erklärt.

      Vielleicht noch eine Frage. Wann steigt ein Pakte aus rolling nach tested auf, bzw. gibt es da feste Kriteren oder eine generelle QA, mit automatisierten Tests ob ein Pakte in der Gesamtkonstruktion funktioniert? Irgendwo las ich mal was wie sinngemäß „wenn nach ein paar Tagen keine Flammen rausschlagen kommt es in testing“. Gerne auch ein Link.

      1. Avatar von tuxnix
        tuxnix

        Solche Pakete kommen nicht nach ‚unstable‘, es gibt bei Debian auch noch ein ‚experimental‘. Aber ob man damit auch Feuer machen kann weiß ich nicht. 🙂

        Ein Link? Bitteschön: https://www.debian.org/doc/manuals/developers-reference/pkgs.de.html#the-testing-distribution

        1. Avatar von Graf Zahl
          Graf Zahl

          Oh … die Dokumentation, wie soll man darauf kommen 😉

    2. Avatar von Gerrit

      Einige Punkte stimmen sicherlich.

      Bei anderen glaube ich, dass Debian Opfer seiner eigenen Marketingstrategie wird. So ist immer die Rede von „Debian wird veröffentlicht wenn es fertig ist“, was schon lange nicht mehr stimmt und „Fertig ist Debian, wenn es frei von schweren Fehlern ist“. Letzteres ist Definitionssache, ein Bug hat schließlich nicht automatisch den Stempel „Release Critical“ und viele Anwender, die dann über Fehler stolpern, wundern sich dann darüber.

      Zumal diese dann meistens auch nicht mehr behoben werden und das ist das letzte große Problem von Debian. Die Qualität hängt durch die Art wie Debian nach dem Freeze mit den Paketen umgeht stark von den Kenntnissen der Paketbetreuer ab. Updates von Upstream einfach weiterreichen, wie dies bei vielen Distribution geschieht kann „jeder“. Patches, auch in großer Zahl auf ältere Versionen zurück portieren und das ggf. ohne viel Unterstützung von Upstream ist dagegen eine andere Hausnummer.

  5. Avatar von Charon
    Charon

    Weiß jemand wie die Pakete heißen zum entfernen, bzw die ganzen Gnome Spiele?! Über synaptic erwas fordernd. Über eine Antwort würde ich mich freuen.

    1. Avatar von Ferdinand

      Meinst Du das Paket gnome-games? Unter welcher Distribution?

      1. Avatar von Charon
        Charon

        Unter Debian 11 rc2 Gnome habe ich die ganzen Gnome Spiele welche ich entfernen möchte. Sind bestimmt 20.

        1. Avatar von Ferdinand

          apt purge gnome-games sollte reichen.

          1. Avatar von Charon
            Charon

            Eins wurde entfernt, der Rest ca 19 noch da. Kenne die Namen der Pakete nicht daher müsste ich jedes einzeln über Synaptic entfernen. Ziemlich ätzend 😀

          2. Avatar von tuxnix
            tuxnix

            Fehlt dir vielleicht diese Liste?
            https://packages.debian.org/buster/gnome-games

            Wenn ich mich recht erinnere, langt es auch sie in synaptic anzukreuzen. Das Entfernen geht dann in einem Rutsch.

            P.S.: gnome-games ist ein meta-paket.
            Wenn du nicht alle davon abhängigen Pakete willst, solltest du von Anfang an nur die einzelnen Pakete installieren.

          3. Avatar von Charon
            Charon

            Vielen Dank! Es klappt:D

          4. Avatar von Ferdinand

            Ich hab von GNOME und von Spielen generell wenig Ahnung 🙁

          5. Avatar von Nick
            Nick

            Wie bereits erwähnt wurde ist das Paket „gnome-games“ ein Metapaket, was gewissermaßen Abhängigkeiten zusammen schnürt. Dieses zu löschen bewirkt zunächst nichts, wenn nicht im Anschluss ebenfalls „apt autoremove“ ausgeführt wird, wonach alles entfernt wird was keinerlei Abhängigkeiten mehr erfüllt. Allerdings ist ein Metapaket auch grundsätzlich mit Vorsicht zu geniessen, zumal einige davon überaus tiefgreifende Abhängigkeiten beherbergen, womit deren Entfernung unmittelbar nach sich ziehen kann, dass gemäß Abhängigkeiten plötzlich das halbe System gelöscht werden soll, was katastrophale Folgen hätte wenn man das bestätigt. Will man dagegen die völlige Freiheit hinsichtlich installierter Pakete haben, so sollte man von Anfang vermeiden das typische Metapakete überhaupt installiert werden. Daher wählt man im Installer idealer Weise alle grafischen Desktops ab, womit zunächst nur das Grundsystem von Debian installiert wird. Und im Anschluss installiert man nach dem Neustart, schlicht alles einzeln an Paketen nach, und vermeidet somit die übliche Flut an üblichen Paketen. Andererseits sollte man Metapakete aber auch nicht verteufeln, zumal diese viele statistisch ermittelte Pakete mitbringen, die die meisten Nutzer ohnehin benötigen bzw. sowieso nachträglich installiert hätten. Daher sollte jeder für sich entscheiden, welche Variante einem mehr entgegen kommt.

          6. Avatar von Charon
            Charon

            Danke für die Rückmeldung, habe die ganzen Gnome Spiele entfernt. Etwas umständlich gemacht aber durchaus kein Problem. Bin froh jetzt Debian 11 mit echt gutem Wayland Support nutzen zu können. Ubuntu ist für mich keine Option mehr, da selbst Pakete in main schlecht gepflegt werden, Beispielsweise der Thunderbird wie hier doch sehr Stiefmütterlich behandelt und auf Snap verwiesen.

  6. Avatar von Nick
    Nick

    Ich möchte noch darauf hinweisen, dass sich mit Debian 11 etwas wesentliches hinsichtlich Passwörtern ändert. Denn das bisher genutzte SHA512_Crypt, wird nun durch ein wesentlich moderneres und sichereres Verfahren namens „yescrypt“ ersetzt. Und dieses ist explizit inkompatibel zu allem vorangegangenen, weshalb man bei einem direkten Upgrade aufpassen und Passwörter idealer Weise neu setzen sollte. Bei einer Neuinstallation sind keine Probleme zu erwarten. Ich hatte zwar keine Probleme damit, bin aber vorsichtshalber dennoch umgestiegen um potentielle Reibereien zu vermeiden. Auf jeden Fall erfreulich das sich auch dieser Bereich weiterentwickelt.

  7. Avatar von MaxMustermann
    MaxMustermann

    Wie lange ist der Updatezeitraum? Ich verwende seit 2012 Ubuntu und installiere alle vier Jahre mal neu und miste dabei aus.

    Ich würde gern mal wieder ne weile Debian nutzen aus Gründen die jetzt zu weit führen. Aber nur zwei Jahre ist mir zu wenig. Mit distupgrades hatte ich 2002 oder so massive Probleme bei Debian, bin dann auf Redhat umgestiegen.

    1. Avatar von Ferdinand

      Die reguläre Unterstützung endet nach rund 3 Jahren. Seit 2014 gibt es Debian LTS, der seitdem weiter ausgebaut wurde. Dass dist-upgrades Schaden anrichten ist selbst unter Debian Sid heutzutage eher selten.

      1. Avatar von maximilianmustermann
        maximilianmustermann

        Ok Dank für die Antwort, mal sehen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert