Das Chromium-Update-Problem

[kvg]

Ja, hoffe auch, dass es bei Firefox weiter rund läuft.
Gerade stottert es aber beim Wechsel der ESR-Versionen von Firefox und Thunderbird auch etwas…

Als Anwender und bestenfalls interessierter Laie frage ich mich, ob der konservative Versionierungsansatz von Debian vielleicht nicht mehr zu der dynamischen Entwicklung von Webbrowsern etc. passt. Klingt ja auch in dem oben zitierten Chromiun-Remove-Request an.
Also doch künftig Flatpack, Snap oder Appimage? Zumindest für sowas?

[tijuca]

Ja, hoffe auch, dass es bei Firefox weiter rund läuft.
Gerade stottert es aber beim Wechsel der ESR-Versionen von Firefox und Thunderbird auch etwas…

Als Anwender und bestenfalls interessierter Laie frage ich mich, ob der konservative Versionierungsansatz von Debian vielleicht nicht mehr zu der dynamischen Entwicklung von Webbrowsern etc. passt. Klingt ja auch in dem oben zitierten Chromiun-Remove-Request an.

Woran machst Du einen "konservativen Ansatz" für FF und TB fest?
Mal auf die jeweiligen Trackerseiten geschaut um vielleicht besser beurteilen zu können warum es gerade stottert?

PS: Es hat auch in der Vergangenheit immer etwa gedauert bis nach dem Release einer neuen Debian Version alle Tools insoweit aktualisiert waren, dass FF und TB erfolgreich gebaut werden konnten und auch alle Abhängigkeiten erfüllt sind. Aktuell kommt neben der Veröffentlichung von Debian 11 auch noch der Sprung der ESR Version dazu.

[mcb]

Ja, hoffe auch, dass es bei Firefox weiter rund läuft.
Gerade stottert es aber beim Wechsel der ESR-Versionen von Firefox und Thunderbird auch etwas…

Als Anwender und bestenfalls interessierter Laie frage ich mich, ob der konservative Versionierungsansatz von Debian vielleicht nicht mehr zu der dynamischen Entwicklung von Webbrowsern etc. passt. Klingt ja auch in dem oben zitierten Chromiun-Remove-Request an.

Woran machst Du einen "konservativen Ansatz" für FF und TB fest?
Mal auf die jeweiligen Trackerseiten geschaut um vielleicht besser beurteilen zu können warum es gerade stottert?

PS: Es hat auch in der Vergangenheit immer etwa gedauert bis nach dem Release einer neuen Debian Version alle Tools insoweit aktualisiert waren, dass FF und TB erfolgreich gebaut werden konnten und auch alle Abhängigkeiten erfüllt sind. Aktuell kommt neben der Veröffentlichung von Debian 11 auch noch der Sprung der ESR Version dazu.

Nun ja ich habe aus persónlichem Interesse wirklich gesucht, das es bei testing dauert verstehe ich. Wie das ganze für Stable funktionieren soll ? Es braucht u.a. einen neuen rust Kompiler - da beißt sich die Stablekette selbst in den Schwanz? "Firefox ESR 91 Creating Massive Headache for Debian 11 (GNU_Linux) | Techrights"
http://techrights.org/2021/11/10/firefox-esr-91-issues/

[kvg]

Hallo!
Ich meinte keinen konservativen Ansatz für TB und FF, sondern für die restliche Software, die ja in stable und oldstable in der Regel "nur" "targeted" Fixes erhält und ansonsten auf dem Versionsstand bei Erscheinen gehalten wird. Normalerweise ist genau das einer der Gründe, weshalb ich Debian einsetze.
Aber wenn zwischendurch selbst im ESR-Zweig zig neue Versionen von FF (und TB, auch wenn es da nicht ESR genannt wird) erscheinen, stottert es eben beim Versionsübergang. S. auch MCBs Beitrag.
Wie gesagt, das ist keine Kritik, ich verstehe durchaus, dass es beim Wechsel der ESR-Versionen stottert, zumal bei TB die letzte 78er (.15) ja auch sang und klanglos entfallen ist. Ich überlegte halt nur aus der Sicht des Laien, ob in diesen Sonderfällen Flatpaks o.ä. doch ihre Vorteile haben könnten.

[mcb]

Ja naürlich haben die bösen Flatpaks oder Upstream Versionen "Vorteile" gegenüber älteren Versionen mit bekannten Sicherheitslücken, leider auch andere "Nachteile".

Gibt Leute die die Developer Edition von Firefox eisetzen, um nicht nur alle paar Wochen Sicherheitspatches zu bekommen.

PS: die Anführungszeichen sind nicht ohne Grund gesetzt.

[tijuca]

Nun ja ich habe aus persónlichem Interesse wirklich gesucht, das es bei testing dauert verstehe ich. Wie das ganze für Stable funktionieren soll ? Es braucht u.a. einen neuen rust Kompiler - da beißt sich die Stablekette selbst in den Schwanz? "Firefox ESR 91 Creating Massive Headache for Debian 11 (GNU_Linux) | Techrights"
http://techrights.org/2021/11/10/firefox-esr-91-issues/

Interessant wie Außenstehende versuchen die aktuelle Lage zu deuten, mir sind keine Informationsanfragen, die nicht direkt den Debian Projekt Beteiligten kommen, bekannt. Der überwiegende Teil in diesem Post sind reine Vermutungen. Warum ich das von mir gebe, weil ich in den ganzen Prozess für die Aktualisierung der benötigten Software indirekt beteiligt bin.

Die Sache ist für unstable/testing an sich komplett gleich wie in (old)stable.

Es fehlt aktuell rein an den nötigen Buildtools um FF oder TB für stable oder oldstable bauen zu können, so wie es bisher immer war wenn neue ESR-Versionen mal wieder eine aktuellere Kette an Cargo, Rust, LLVM etc. benötigt haben. Das ist alles nicht zufriedenstellend, ja, aber Debian hat keine fest angestellten Entwickler wie Ubuntu oder SuSE z.B. Eine Toolchain zu aktualisieren ist mit einigem Aufwand verbunden und lässt sich nur bedingt vorbereiten.

[mcb]

Habe ich das jetzt richtig verstanden, das Debian keine Pakete ausliefert, de man nicht unter dem Tagetrelease bauen kann? (Außschließlich mit den mitgelieferten Tools, die sich nicht ändern sollen).

^^ etwas vereinfacht.

[MSfree]

Habe ich das jetzt richtig verstanden, das Debian keine Pakete ausliefert, de man nicht unter dem Tagetrelease bauen kann? (Außschließlich mit den mitgelieferten Tools, die sich nicht ändern sollen).

Genau das ist das Problem.

Für aktuellere FF/TB braucht man Compiler, die neuer sind als die, die im aktuellen Stable sitzen, von Oldstable brauchen wir gar nicht erst anzufangen. Und weil Stable nunmal nicht für stabil, im Sinne von Absturzfreiheit steht, sondern für starre Softwareversionen, darf sich die Compilerversion hier nicht ändern.

[kvg]

Auch wenn es damit nochmal etwas Richtung OT abgleitet:
Für Firefox bin ich jetzt doch auch erst mal auf das Flatpak umgestiegen, bis Debian die neue ESR-Version in den Repositories hat.

Die Flatpak-Version läuft problemlos, wird bei Flathub offiziell von Mozilla bereit gestellt und hat komplett eigene Profile (~/.var/app), unabhängig von denen des Debian-Firefoxes.
Je nach weiterem Verlauf überlege ich das auch für Thunderbird.

Sobald Debian "wieder im Takt" mit den neuen Versionen ist, schalte ich zurück.

[mcb]

Auch wenn es damit nochmal etwas Richtung OT abgleitet:
Für Firefox bin ich jetzt doch auch erst mal auf das Flatpak umgestiegen, bis Debian die neue ESR-Version in den Repositories hat.

Die Flatpak-Version läuft problemlos, wird bei Flathub offiziell von Mozilla bereit gestellt und hat komplett eigene Profile (~/.var/app), unabhängig von denen des Debian-Firefoxes.
Je nach weiterem Verlauf überlege ich das auch für Thunderbird.

Sobald Debian "wieder im Takt" mit den neuen Versionen ist, schalte ich zurück.

Von Mozilla gibt es auch Binaries - die kann man sich einfach in einen Ordner entpacken. Und ja flatpaks kommen den Profilen der Installation nicht in den Weg.

[kvg]

Nachdem sich bei Chromium ja jetzt wirklich ewig nicht mehr aktualisiert wurde, es lt. der weiter oben verlinkten Diskussion als "unmaintained" entfernt werden soll und auch aus "Testing" geflogen ist, hätte ich erwartet, dass das aktuelle .2-Release das auch für Bullseye vollzieht, oder trügt mich die Erinnerung, dass bei Point-Releases gelegentlich auch Pakete entfernt wurden?

[mcb]

Pakete werden manchmal entfernt -> man kann sie dann nicht mehr neu installieren, das installierte Programme entfernt werden habe ich noch nicht erlebt.

Code: Alles auswählen

[marc@station2:~$ rmadison chromium
chromium   | 57.0.2987.98-1~deb8u1   | oldoldoldstable    | amd64, i386
chromium   | 70.0.3538.110-1~deb9u1  | oldoldstable       | armhf
chromium   | 73.0.3683.75-1~deb9u1   | oldoldstable       | source, amd64, arm64, i386
chromium   | 73.0.3683.75-1~deb9u1   | oldoldstable-debug | source
chromium   | 89.0.4389.114-1~deb10u1 | oldstable          | source, amd64, arm64, armhf, i386
chromium   | 89.0.4389.114-1~deb10u1 | oldstable-debug    | source
chromium   | 90.0.4430.85-1~deb10u1  | oldstable-new      | source, amd64, i386
chromium   | 90.0.4430.93-1~deb10u1  | oldstable-new      | source, amd64, armhf, i386
chromium   | 90.0.4430.212-1~deb10u1 | oldstable-new      | source, amd64, armhf, i386
chromium   | 90.0.4430.212-1         | stable             | source, amd64, arm64, armhf, i386
chromium   | 93.0.4577.82-1          | unstable           | source, amd64, arm64, armhf, i386
chromium   | 93.0.4577.82-1          | unstable-debug     | source
/code]

[mcb]

Good news!

Code: Alles auswählen

apt policy chromium
chromium:
  Installed: (none)
  Candidate: (none)
  Version table:
     97.0.4692.71-0.1~deb11u1 -1
        500 http://deb.debian.org/debian-security bullseye-security/main amd64 Packages
     90.0.4430.212-1 -1
        500 http://ftp.de.debian.org/debian bullseye/main amd64 Packages

Ob es so bleibt oder auch nicht ...

[slu]

Tatsächlich hatte ich damit überhaupt nicht mehr gerechnet.
Bleibt die Frage ob man sich da zukünftig wieder drauf verlassen kann oder eher nicht...

[Blackbox]

Von der Realität widerlegt zu werden ist bitter, weiter so Debian Projekt!

[mcb]

Nach dem Patch ist vor dem Patch, warten wir mal ab:

Code: Alles auswählen

rmadison chromium
chromium   | 57.0.2987.98-1~deb8u1    | oldoldoldstable     | amd64, i386
chromium   | 70.0.3538.110-1~deb9u1   | oldoldstable        | armhf
chromium   | 73.0.3683.75-1~deb9u1    | oldoldstable        | source, amd64, arm64, i386
chromium   | 73.0.3683.75-1~deb9u1    | oldoldstable-debug  | source
chromium   | 89.0.4389.114-1~deb10u1  | oldstable           | source, amd64, arm64, armhf, i386
chromium   | 89.0.4389.114-1~deb10u1  | oldstable-debug     | source
chromium   | 90.0.4430.85-1~deb10u1   | oldstable-new       | source, amd64, i386
chromium   | 90.0.4430.93-1~deb10u1   | oldstable-new       | source, amd64, armhf, i386
chromium   | 90.0.4430.212-1~deb10u1  | oldstable-new       | source, amd64, armhf, i386
chromium   | 90.0.4430.212-1          | stable              | source, amd64, arm64, armhf, i386
chromium   | 97.0.4692.71-0.1~deb11u1 | stable-new          | source, amd64, arm64, armhf, i386
chromium   | 97.0.4692.71-0.1         | unstable            | source, amd64, arm64, armhf, i386
chromium   | 97.0.4692.71-0.1         | unstable-debug      | source
chromium   | 97.0.4692.99-1           | buildd-unstable     | source, i386
chromium   | 97.0.4692.99-1           | unstable            | source, i386
chromium   | 97.0.4692.99-1           | unstable-debug      | source
chromium   | 99.0.4818.0-0.1          | buildd-experimental | source, amd64, i386
chromium   | 99.0.4818.0-0.1          | experimental        | source, amd64, i386
chromium   | 99.0.4818.0-0.1          | experimental-debug  | source

Ich lasse mich immer gerne positiv überraschen.

[mcb]

Jo so wünscht man sich das:

Code: Alles auswählen

apt policy chromium
chromium:
  Installed: (none)
  Candidate: (none)
  Version table:
     97.0.4692.99-1~deb11u2 -1
        500 http://deb.debian.org/debian-security bullseye-security/main amd64 Packages
     97.0.4692.71-0.1~deb11u1 -1
          1 http://deb.debian.org/debian bullseye-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     90.0.4430.212-1 -1
        500 http://ftp.de.debian.org/debian bullseye/main amd64 Packages

[atarixle]

Leider beachtet Chromium 97 unter GNOME-Shell/Wayland nicht die Einstellungen der Schriftgröße via GNOME-Tweak. Chromium 90 sowie Chromium 97 unter GNOME-Shell/X11 tun dies.
Kein Dealbreaker - aber unter Wayland lief Chromium gefühlt schneller.

[mcb]

Das ist richtig - ich tue mir sowieso mit Chrome/Chromium schwer -

ich versuche es im Moment mit Firefox ESR und Firefox Developer Edition (als Binary). Aber immer gut wenn es noch eine Alternative gibt.

[mcb]

Chrome 98.0.4758.102 fixt gravierende Schwachstellen | Borns IT- und Windows-Blog
https://www.borncity.com/blog/2022/02/1 ... chstellen/

betrifft wohl auch den Chromium:
https://tracker.debian.org/pkg/chromium

Sicherheitstechnisch ist Chromium wohl subobtimal.

[Blackbox]

chromium wird doch bereits vom Debian Security Team betreut, also was soll die Hysterie?