Cordess
(Themenstarter)
Anmeldungsdatum: 14. Mai 2006
Beiträge: 466
|
Und nicht unerwähnt lassen muss ich die Tatsache, dass ich die Art und Weise, wie du die Wiki nutzen willst, ausgesprochen doof finde. Denn kein Wiki Artikel der Welt ist von Anfang perfekt, es gibt immer etwas zu verbessern, eine Wiki ist normalerweise dazu da, dass man einen Artikel anfängt und dann in der Gemeinschaft dieser immer weiter verbessert wird. Deine Regel, dass ein Artikel unter Ubuntu getestet sein muss und alles schon drin sein muss, bevor er überhaupt in die Wiki darf, ist also, und anders kann man das nicht sagen, schlichtweg dumm, weil so alle positiven Eigenschaften einer Wiki, also das andere den Artikel ergänzen und ihren Beitrag dazu leisten können, so wegfallen und der Artikel eine Baustelle bleibt und diese erst dann verlässt, wenn der Ursprungsautor überhaupt die Bereitschaft hat, den noch überhaupt weiter zu entwickeln, so wie ich es jetzt getan habe.
Mein Artikel war schon im Januar gebrauchsfertig und hätte auch, so wie er damals war, unter 20.04 out of the box ungetestet funktioniert, so wie das auch jetzt bei 21.10 der Fall war und dann hätte man die Kleinigkeiten an denen newubunti Änderungswünsche hatte, noch später ergänzen können. Vor allem hätte sich jeder dann einbringen können und es hätte welche gegeben, die den Artikel gefunden und daher sowieso getestet hätten, weil sie die Funktioin vielleicht damals brauchten. Der Artikel wäre also heute viel weiter und nicht nur unter 21.10 getestet, sondern sicherlich auch unter anderen Versionen.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Cordess schrieb: Wieso installierst du am Paketrepository vorbei, wenn es von den TigerVNC Machern Deb Pakete für Ubuntu gibt?
Weil ich einfach nur ausschließen wollte, dass es an meinem Setup mit der VM liegt. Und das konnte ich damit ausschließen. Dafür war die Vorgehensweise ausreichend. Ich schreibe mein ganzes Vorgehen nur so ausführlich, weil Du mit Ubuntu nicht getestet hast (nur eine Feststellung!), so dass es halbwegs nachvollziehbar ist. Ich schreibe das nicht, damit alles davon in den Artikel kommt. Insgesamt kann ich nach meinem Test sagen, dass das Problem hier wohl in erster Linie daran liegt, dass die TigerVNC-Entwickler wohl über einige Versionen hinweg Probleme damit hatten/haben, dass im Zusammenspiel mit Gnome - das kann ich bestätigen - und wohl auch mit Plasma zum Laufen zu bekommen - insbesondere noch im Zusammenspiel mit systemd. Da kannst jetzt weder Du noch Dein Artikel etwas dafür, aber es ist halt schon insofern problematisch, weil halt der Stamm-Desktop Gnome bei Ubuntu ist - davon dann wahrscheinlich also ein größerer Teil von Nutzern betroffen sein wird. Ich gehe übrigens auch davon aus, dass man es unter Ubuntu 20.04 durchaus auch mit der "richtigen" tigvervncserver@.service Datei hinbekommen können sollte - aber nicht so wie im Artikel beschrieben. Hast Du das ganze unter Debian mal mit Gnome versucht? Weil ich vermute, dass es da unter Debian auch eher Probleme mit gibt, als mit LXDE oder XFCE. LG,
Newubunti
|
Cordess
(Themenstarter)
Anmeldungsdatum: 14. Mai 2006
Beiträge: 466
|
Newubunti schrieb: > Da kannst jetzt weder Du noch Dein Artikel etwas dafür, aber es ist halt schon insofern problematisch, weil halt der Stamm-Desktop Gnome bei Ubuntu ist - davon dann wahrscheinlich also ein größerer Teil von Nutzern betroffen sein wird.
Dann sollte die tigervnc Version schnellstmöglich in Debian sid aktualisiert werden, ehe für Ubuntu 22.04 ein Fork erstellt wird.
Dann wäre die neue Version nämlich im regulären Ubuntu Repo drin.
Ich gehe übrigens auch davon aus, dass man es unter Ubuntu 20.04 durchaus auch mit der "richtigen" tigvervncserver@.service Datei hinbekommen können sollte - aber nicht so wie im Artikel beschrieben.
In 5 Monaten kommt 22.04 LTS, ich würde mir da jetzt keinen Kopf mehr um 20.04 machen. Das wir dann 2 Jahre alt sein. Sinnvoll wären aber neue Pakete von tigevnc in der neuen Version, dazu solltest du den Debian Maintainer informieren.
Mich persönlich betrifft das noch nicht, der nächste stable Release von Debian kommt erst Mitte 2023 und auf dem Raspi läuft kein Gnome.
Hast Du das ganze unter Debian mal mit Gnome versucht? Weil ich vermute, dass es da unter Debian auch eher Probleme mit gibt, als mit LXDE oder XFCE.
Auf dem Rapsberry Pi habe ich nur LXDE laufen und das war mein Rechner, den ich remote auf meinem PC darstellen wollte.
Auf meinem Clientrechner nutze ich kein Gnome, sondern KDE. Die Konstellation ist aber so, dass ich auf dem Remoterechner lokal ausgeloggt bin. Der Raspi ist so konfiguriert, das ein Loginscreen kommt und der stört nicht. EDIT: Feature Freeze von Ubuntu bezüglich dem Import von Paketen aus Debian ist laut Plan am 24. Februar.
https://discourse.ubuntu.com/t/jammy-jellyfish-release-schedule/23906 Bis dahin sollte also alles in Debian sid sein, was in Ubuntu 22.04 enthalten sein soll. Unter Debian sieht es mit dem Paket momentan so aus:
https://tracker.debian.org/pkg/tigervnc
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Cordess schrieb: Nein, das muss er nicht. Der Artikel ist dazu da, Remote via VNC eine performante Bedienung des Remotecomputers zu ermöglichen ohne dass man sich lokal einloggt.
Dann muss man ihn beim Verschieben aber "TigerVNC-Standalone-Server" umbenennen und in der Einleitung sollte er es dann auch konkret so beschrieben werden. Dort ist eben nur von TigerVNC die Rede und das beinhaltet nun mal auch x0tigervncserver .
Das ist nämlich nicht der wesentliche Sinn und Zweck von VNC, auch wenn es unter Performanceeinbußen über X11 Bildausgabe abkopieren mit dem Scrapping Server möglich ist.
Ob nun wesentlicher Zweck oder nicht, unter TigerVNC fällt nun mal auch x0tigervncserver . Da ändert auch die Tatsache nichts, dass das Abkopieren der Bildausgabe nicht so performant ist. Es gibt auch für diesen Bereich einen Anwendungsfall.
Er ist NICHT dazu da, das Handbuch zu ersetzen.
Ich fordere keine Handbuch, ich fordere nur klare Erklärungen und Abgrenzungen. Siehe auch mein Verbesserungsvorschlag weiter oben bezüglich der automatischen Passwortübermittlung. Man findet im Internet genügend Anfragen dazu, wie man sich mit tigervncserver gleichzeitig lokal eingeloggen und zugleich von der Ferne auf den Desktop zugreifen kann. Dafür ist es aber nicht konzipiert. Für Dich mag das absolut klar sein. Das darf man dem Leser aber ruhig in einem Satz erklären und auch darauf hinweisen, dass es dafür x0tigervncserver gibt, denn vielen Lesern wird das sicher nicht klar sein. Das hat mit Handbuch nichts zu tun, sondern das gehört für mich schlicht zu Stil eine Artikel-Einleitung. Ich habe kein Problem damit, dass der Artikel "nur" tigervnc-standalone-server behandelt, mich stört nur, dass er das in der Einleitung nicht klipp und klar zum Ausdruck bringt, sondern als Artikel allgemein für TigerVNC auftritt. Und ein Artikel insgesamt für TigerVNC ist er nicht, sondern eben ein Artikel für tigervnc-standalone-server. LG,
Newubunti EDIT: Cordess schrieb: Bisher habe, abgesehen von minimalen Änderungen im Januar, nur ich ihn angepasst.
Falls Du möchtest bzw. erwartest, dass ich meine Verbesserungsvorschläge direkt selbst in den Artikel einbaue, dann musst Du das sagen. Normalerweise bin ich es hier gewohnt, dass der Autor des Artikels vor Erst-Veröffentlichung selbst die vorgeschlagenen Verbesserungen einpflegt. Zumindest ist das sehr häufig so. Ich kann die Präzisierungen die ich mir für den Artikel wünsche aber auch direkt selbst einbauen. Das würde dann die Diskussion hier unter Umständen abkürzen. LG,
Newubunti
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Hallo Cordess, Cordess schrieb: Das einzige was man noch ändern könnte, wäre, sytemd so zu konfigurieren, dass der VNC Server neu gestartet wird, falls der Nutzer sich via vnc eingeloggt und dann im remote Desktop ausgeloggt hat, anstatt das Fenster mit der VNC Sitzung einfach zu schließen.
Dieses remote ausloggen auf dem Server über die Auslogbuttons des Desktops bewirkt nämlich, dass auch der vnc server beendet wird und dann nicht mehr zur Verfügung steht, es sei denn, der Nutzer startet ihn über systemd manuell oder bootet die Remote Maschine.
Da habe ich aber leider noch keine zufriedenstellende Lösung gefunden. Man kann zwar systemd dazu veranlassen, dass beendete Server wieder gestartet werden, aber im Fall von tigervnc führt das aus mir noch unerfindlichen Gründen zu ständigen Beendigungen und Neustarts des Servers und somit zu vielen Logeinträgen.
Da ich jetzt auch mal mit Xubuntu 21.10 als VNC-Server-PC getestet habe: Also erstens habe ich den Eindruck, dass das ein spezielles Problem mit XFCE ist, weil dort auch das Problem besteht, dass man den Logout-Button über xfconf-query NICHT deaktivieren kann, während man das bei den beiden Knöpfen "Hibernate" und "Shutdown" sehr wohl kann. Ich kann mir gut vorstellen, dass das die VNC-Entwickler nicht berücksichtigt haben bzw. vielleicht lässt sich das Problem auch nicht so ohne weiteres von deren Seite lösen. Ich habe aber folgende Lösung für Xubuntu mit dem Whiskermenü gefunden: Man ändert einfach die Einstellung im Whiskermenü (~/.config/xfce4/panel/whiskermenu-1.rc) für das logout-command von xfce4-session-logout nach z.B. notify-send . Also von:
...
command-logout=xfce4-session-logout
show-command-logout=true
... Nach z.B.:
...
command-logout=notify-send -t 5000 "Logout-Menü ist deaktiviert!" "Zum Beenden der Sitzung bitte einfach das VNC-Viewer-Fenster schließen."
show-command-logout=true
...
Damit kann der Nutzer über diesen Weg nicht mehr versehentlich die Session am Server komplett abschießen. Falls sich der Nutzer doch auch mal lokal einloggt, dann kann er ja immer noch xfce4-session-logout explizit z.B. über das Terminal ausführen. Es gibt zwar auch noch die Möglichkeit, über die Datei ~/.vnc/Xtigervnc-session das Verzeichnis ~/.config durch setzen der Variable $XDG_CONFIG_HOME auf z.B. ~/.config-vnc für die ganze VNC-Sitzung umzubiegen, allerdings befürchte ich, dass zu viele Anwendungen direkt in ~/.config etwas ablegen/ändern/lesen und $XDG_CONFIG_HOME nicht berücksichtigen, auch wenn sie gesetzt ist - denn standardmäßig ist die zumindest unter Ubuntu leer. Man könnte aber auch noch probieren, zwei ~/.config/xfce4/panel/whiskermenu-1.rc zu führen und per ~/.vnc/Xtigervnc-session einen symbolischen-Link auf z.B. eine ~/.config/xfce4/panel/whiskermenu-1-vnc.rc zu setzen. Beim lokalen Einloggen wird dann z.B. über .bashrc oder so, der symbolische Link auf ~/.config/xfce4/panel/whiskermenu-1-local.rc gesetzt. Im Prinzip könnte man so das gesamte xfce4-Einstellungsverzeichnis symbolisch je nach Login verknüpfen. Ich muss auch noch anmerken, dass die mit dem Tigervncserver-Paket ausgerollte /etc/X11/Xtivervnc-session nicht ausreichend ist, um eine virtuelle Sitzung zu eröffnen, die optisch der lokalen *buntu-Sitzung entspricht. Es ist (optisch) jeweils immer nur die Grundversion der betreffenden Desktop-Umgebungen. Das lässt sich aber lösen, indem man die /etc/X11/Xtivervnc-session nach ~/.vnc/ kopiert, die Rechte anpasst und dann die XDG-Variablen bezüglich der Desktop-Umgebung alle richtig setzt. LG,
Newubunti
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Da hier über mehrere Wochen nun keine Rückmeldung mehr kam, habe ich mir mal eine Umstellung des Artikels zu Anschauungszwecken erlaubt, die IMO etwas weiter in Richtung Wiki-Konformität führt. Das soll bitte nicht als EDIT-War ausgelegt werden. Es ist IMO aber einfacher, meine Vorschläge zu veranschaulichen, anstatt sie nur theoretisch zu unterbreiten. Wesentliche Änderungen im Überblick:
Etwas mehr Einleitung Abschnitt Konfiguration gestrafft und etwas besser auf die Vorgaben des Pakets eingegangen sudo cp /lib/systemd/system/tigervncserver@.service /etc/systemd/system/ dieser Befehl ist überflüssig und entspricht so ohne weiteres auch nicht der systemd-Struktur
Im Skript wir der Port nun aus dem Displaynamen berechnet.
Ich würde übrigens den Artikel zu diesem Zeitpunkt noch nicht veröffentlichen, sondern abwarten, bis der Freeze für 22.04 erfolgt ist. Dann kann man sehen, ob es die 1.12er Version von tigervnc.org noch in 22.04 geschafft hat. Außerdem kann ich nun noch definitiv sagen, dass die 1.11er-Version im Zusammenspiel mit systemd NICHT in der Lage ist, die gnome-session sauber einzurichten. Das gilt im übrigen - wie auch erwartbar - in gleicher Weise für Debian - und vermutlich ist das Problem auch nicht auf Debian-basierte Distributionen beschränkt. Wenn es die 1.12er nicht in 22.04 schafft, dann würde ein HowTo zum Kompilieren von TigerVNC Sinn ergeben, da ja Gnome nun mal der Standard-Desktop von Ubuntu ist. Je nachdem, was aus der Überarbeitung von VNC wird, könnte man in diesem Artikel hier eventuell auch auf den Viewer-Teil (Client-Teil) verzichten. Danke! LG,
Newubunti
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29065
Wohnort: WW
|
Hallo,
sondern abwarten, bis der Freeze für 22.04 erfolgt ist.
Ok. Bitte das Fertigstellungsdatum dann entsprechend anpassen. Gruß, noisefloor
|
gypakk
Anmeldungsdatum: 7. März 2008
Beiträge: Zähle...
|
Hallo zusammen! Ich finds super, dass ihr euch um einen Artikel um TigerVNC bemüht! Ich hab eine Weile nach einer guten praktischen Anleitung gesucht und dann über einen kleinen Umweg diesen Artikel gefunden. Umweg deswegen, weil er ja erst nach dem Einloggen sichtbar wird. Eine der Besonderheiten bei TigerVNC scheint zu sein, dass man damit eine verschlüsselte VNC-Verbindung auch ohne externen SSH-Tunnel starten kann. Habt ihr diesen Weg mal ausgelotet?
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
gypakk schrieb: Eine der Besonderheiten bei TigerVNC scheint zu sein, dass man damit eine verschlüsselte VNC-Verbindung auch ohne externen SSH-Tunnel starten kann. Habt ihr diesen Weg mal ausgelotet?
Also was mich betrifft:
Nein, bis jetzt nicht und mir würde auch die Expertise fehlen, um die Qualität der Implementierung dieser Funktion einschätzen zu können. VNC im SSH-Tunnel ist dagegen "altbewährt". LG,
Newubunti
|
Cordess
(Themenstarter)
Anmeldungsdatum: 14. Mai 2006
Beiträge: 466
|
gypakk schrieb: Hallo zusammen! Ich finds super, dass ihr euch um einen Artikel um TigerVNC bemüht! Ich hab eine Weile nach einer guten praktischen Anleitung gesucht und dann über einen kleinen Umweg diesen Artikel gefunden. Umweg deswegen, weil er ja erst nach dem Einloggen sichtbar wird.
Danke.
Der Artikel ist schon seit über einem Jahr fertig und hängt immer noch in der Baustelle herum. Wenn es nach mir ginge, wäre er schon lange in der normalen Wiki.
Eine der Besonderheiten bei TigerVNC scheint zu sein, dass man damit eine verschlüsselte VNC-Verbindung auch ohne externen SSH-Tunnel starten kann. Habt ihr diesen Weg mal ausgelotet?
Ja, dies ist im Prinzip möglich. TigerVNC bietet verschiedene Authentifizierungswege an. Ich habe den Artikel aber so geschrieben, dass er immer in eine sichere, also verschlüsselte Remote Verbindung führt und ssh ist hier die bessere Wahl, weil das weitaus besser gepflegt wird und auch viel früher Sicherheitsupdates bekommt.
Das gilt insbesondere für Ubuntu, da tigervnc bei Ubuntu nur Teil des universe Repositories ist und das ist ein sehr großer Nachteil, weil das dann nur von der Community, nicht aber von Canonical, gepflegt wird und es möglich sein kann, dass Sicherheitslücken bekannt werden und dann monatelange nicht gestopft werden, weil sich keiner aus der Community um ein Update des tigervnc Pakets kümmert.
|
Cordess
(Themenstarter)
Anmeldungsdatum: 14. Mai 2006
Beiträge: 466
|
Newubunti schrieb: Da hier über mehrere Wochen nun keine Rückmeldung mehr kam,
Ich habe mich nicht gemeldet, weil der Artikel fertig war und schon längst aus der Baustelle in die normale Wiki gehört. Du hast jetzt mehrere Änderungen vorgenommen, ich musste da wieder einiges korrigieren.
Denn nicht alles deiner Änderungen war richtig.
Wenn die Desktopumgebungen nicht damit klarkommen, dass ein Nutzer mehrfach in diese eingeloggt ist, dann ist das keine Schuld von Tigervnc, sondern eben von den Desktopumgebungen.
Auch hast du den Artikel jetzt nochmals in Kategorien untergliedert, besonders negativ fiel mir hier die Kategorisierung in localhost auf. Denn ein Nutzer, der es eilig hat, wird diesen Abschnitt jetzt nicht lesen und somit die, für eine sichere absolut notwendige $localhost = "yes"; Option überlesen. Das musste ich zur Schadensbegrenzung nochmals deutlich hervorheben, damit die gesetzt ist. Auch nochmals im Abschnitt ssh wo es dann um die Remoteverbindungen geht. Und dann habe ich noch eine ganz dringende Bitte an dich, man sieht das du keine Software entwickelst und daher keine Versionsverwaltung einsetzt, aber es gehört da zum guten Ton, dass man immer nur kleine Änderungen macht und dann für jede kleine Änderung eine neue Version erstellt, also übertragen auf die Wiki, jede Änderung einzeln speichert. Was du gemacht hast, ist ein riesiger EDIT, so ist das schlecht nachvollziehbar.
|
Cordess
(Themenstarter)
Anmeldungsdatum: 14. Mai 2006
Beiträge: 466
|
Newubunti schrieb: Je nachdem, was aus der Überarbeitung von VNC wird, könnte man in diesem Artikel hier eventuell auch auf den Viewer-Teil (Client-Teil) verzichten.
Die verschiedenen VNC Server verwenden teilweise unterschiedliche Authentifizierungsprotokolle und proprietäre, also nicht standardisierte Erweiterungen, was dazu führt, dass rudimentäre VNC Clients meist nur einen Bruchteil dieser umsetzen und man sich mit diesen somit nicht mit dem entsprechenden VNC Server verbinden kann.
Das ist mir schon recht früh aufgefallen, bevor ich den Artikel für tigerVNC geschrieben habe. Momentan ist es also immer noch das beste, wenn man für jede VNC Server Implementierung die dafür auch gedachte VNC Client Implementierung verwendet. Ansonsten müsste man nämlich den kleinsten gemeinsamen Nenner nehmen und das bedeutet momentan dann meist eine VNC Verbindung ohne Verschlüsselung im Klartext. Manche VNC Server bieten bspw. auch Copy & Paste von Text oder von Objekten und manchmal sogar von Dateien an, das kann aber nicht jeder Client und nicht jeder VNC Server setzt das um. Beim Sound ist es ganz genauso. Und viele sind ohne Verschlüsselung oder machen ihr eigenes Ding. Bis die Clients so weit sind, wird das sicherlich noch ein paar Jahre Entwicklungsarbeit bedeuten.
Daher ist eine Auftrennung der Artikel keineswegs empfehlenswert.
|
Cordess
(Themenstarter)
Anmeldungsdatum: 14. Mai 2006
Beiträge: 466
|
Newubunti schrieb: Ich würde übrigens den Artikel zu diesem Zeitpunkt noch nicht veröffentlichen, sondern abwarten, bis der Freeze für 22.04 erfolgt ist. Dann kann man sehen, ob es die 1.12er Version von tigervnc.org noch in 22.04 geschafft hat. Außerdem kann ich nun noch definitiv sagen, dass die 1.11er-Version im Zusammenspiel mit systemd NICHT in der Lage ist, die gnome-session sauber einzurichten. Das gilt im übrigen - wie auch erwartbar - in gleicher Weise für Debian - und vermutlich ist das Problem auch nicht auf Debian-basierte Distributionen beschränkt.
Also ich benutze hier TigerVNC 1.11 mit Raspbian + LXDE auf dem Server und Debian 11 + KDE auf dem Client und tigervnc lässt sich super nutzen. Und ab Ubuntu 21.10 funktioniert die Anleitung auch. Siehe:
https://forum.ubuntuusers.de/post/9288182/ Denn die vorgegebenen Systemd Konfigurationsdateien werden von Debian erstellt, nicht von dem TigerVNC Projekt selber.
Wenn es die 1.12er nicht in 22.04 schafft, dann würde ein HowTo zum Kompilieren von TigerVNC Sinn ergeben, da ja Gnome nun mal der Standard-Desktop von Ubuntu ist.
Tigervnc 1.12 wird es nicht in Ubuntu 22.04 schaffen, weil unter Debian SID (also Upstream) immer noch Tigervnc 1.11 das aktuelle Paket ist.
https://packages.debian.org/search?keywords=tigervnc-standalone-server&searchon=names&suite=all§ion=all und
https://tracker.debian.org/pkg/tigervnc Außerdem habe ich ja im November 2021 schon geschrieben, dass man, wenn man eine noch neuere Version im kommenden Ubuntu haben will, sich an den Debian Maintainer wenden soll, damit der eine neue Version baut.
Siehe:
https://forum.ubuntuusers.de/post/9288189/ Sowie nochmals Anfang Dezember:
https://forum.ubuntuusers.de/post/9288877/ Der Freeze von Ubuntu 22.04 ist am 24 Februar 2022.
Das dürfte der Termin sein, an dem kurz davor letztmalig Pakete aus Debian nach Ubuntu für das kommende 22.04 wandern:
https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-22.04-Release-Schedule Wenn du also willst, dass Ubuntu 22.04 eine neue Version von tigervnc bekommt, dann solltest du den Debian Maintainer anschreiben, damit der die SID Version nochmal schnell updated. Beachte bitte, das das auch seine Zeit braucht.
Jetzt sind es noch höchsten 3 Wochen. Beachte auch, wenn du dann immer ein Paket compilieren willst, dass du dass dann für die nächsten 5 Jahre bei Ubuntu 22.04 LTS machen müsstest.
|
Cordess
(Themenstarter)
Anmeldungsdatum: 14. Mai 2006
Beiträge: 466
|
Ich habe jetzt nochmal etwas genauer nachgesehen. Heute, also vor ca. einer Stunde gab es die Meldung, dass eine neue TigerVNC 1.12 Version nach Debian FTP Master gewandert ist. https://tracker.debian.org/news/1298317/accepted-tigervnc-1120dfsg-1-source-amd64-into-unstable-unstable/ Es besteht also noch eine Chance, dass das rechtzeitig in Ubuntu 22.04 LTS ankommt. Hier nochmal der Release Plan:
https://discourse.ubuntu.com/t/jammy-jellyfish-release-schedule/23906 Debian Import ist bei Ubuntu also am 24.2.2022. Alles, was sich bei Ubuntu in universe oder multiverse befindet und bis dahin in Debian nicht upgedated wurde, schafft es nicht mehr nach Ubuntu 22.04 LTS.
Alles was in main ist, kann noch updates bekommen. Das entscheidet nämlich dann Canonical selber. Tigervnc gehört da aber nicht dazu.
|
Cordess
(Themenstarter)
Anmeldungsdatum: 14. Mai 2006
Beiträge: 466
|
Jetzt ist 1.12 in Debian unstable: rmadison tigervnc-standalone-server
tigervnc-standalone-server | 1.7.0+dfsg-7+deb9u1 | oldoldstable | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
tigervnc-standalone-server | 1.9.0+dfsg-3+deb10u3 | oldstable | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
tigervnc-standalone-server | 1.11.0+dfsg-2 | stable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
tigervnc-standalone-server | 1.11.0+dfsg-3 | testing | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
tigervnc-standalone-server | 1.11.0+dfsg-3 | unstable | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
tigervnc-standalone-server | 1.12.0+dfsg-1 | buildd-unstable | amd64
tigervnc-standalone-server | 1.12.0+dfsg-1 | unstable | amd64
|