gehört Chromium nach non-free?

Du hast Probleme mit Deinem eMail-Programm, Webbrowser oder Textprogramm? Dein Lieblingsprogramm streikt?
Benutzeravatar
hikaru
Beiträge: 10725
Registriert: 09.04.2008 12:48:59

gehört Chromium nach non-free?

Beitrag von hikaru » 07.02.2017 10:59:58

Hallo,

ich wurde auf Bug-Report Debian Bugreport787527 aufmerksam gemacht, der, falls er (noch) zutrifft bedeuten würde, dass Debianchromium eigentlich nach non-free gehört. Der Report ist mit der Schwere "serious" eingestuft, wäre also Release-Critical - mMn als Policy-Violation zurecht.
Aus historischen Gründen ist dieser Report allerdings gegen Debianchromium-browser gerichtet, was in Wheezy ein Übergangspaket war und seit Jessie nicht mehr existiert. Daher taucht der Report nicht als Chromium-Bug auf.

Ich denke nun über ein Re-Assignment des Bugs an Debianchromium nach, würde vorher aber prüfen wollen, ob das Problem mit den fehlenden Quellen immer noch besteht. Weiß da jemand mehr und kann mir etwas Recherche ersparen?


Edit:
Da ich ja immer so auf Querverweisen zu Crosspostings rumreite, hier [1] bekam ich den Hinweis. Ich trete dort als "sulu" auf.

[1] https://pyra-handheld.com/boards/thread ... st-1405495

Benutzeravatar
novalix
Beiträge: 1731
Registriert: 05.10.2005 12:32:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: elberfeld

Re: gehört Chromium nach non-free?

Beitrag von novalix » 07.02.2017 18:00:17

1. Ich habe keine Ahnung
2. Ich verstehe den Bug Report nicht
3. Sucht da tatsächlich jemand nach dem Quellcode von JavaScript-Dateien?
4. Debianapt-file spuckt bei zwei Stichproben der Liste nix aus (stretch und sid auf amd64)
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: gehört Chromium nach non-free?

Beitrag von rendegast » 07.02.2017 20:59:37

novalix hat geschrieben: 3. Sucht da tatsächlich jemand nach dem Quellcode von JavaScript-Dateien?
Ich finde im Source orig.tar.xz 56.0.2924 (450MB, entpackt 2,5GB) jetzt nur die im bugreport angemerkten domdistiller*.
Diese sind imo niemals zusammengeschrieben, also source-Code,
sondern generiert.
Somit fehlt deren Source.
Für andere *.js gilt wohl dasselbe.

*.so oder *.swf finden sich nicht mehr.
Aber

Code: Alles auswählen

# cat chromium-56.0.2924.76.filetype-split | egrep -v "ASCII text|Unicode text|PNG image data|XML document|SPEC$| text$|empty$|MS Windows icon|SVG Scalab|Ogg data|PDF docum|RIFF|HTML docum|data$|SQLite |XML 1.0 docu|ISO-8859 text|UTF-8 Unicode|Java serialization|symbolic link|MSVC progr" | wc -l
800
darunter noch etliche *.exe und PE32, ELF-64/32, JVT NAL sequence und mp4 Mediendateien und weitere Bildchen, *.jar, einige *.dll und wohl auch nicht wenige 'file'-Fehlerkennungen.
Was davon noch nach Anwendung des debian-Patcharchivs übrigbleibt?
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

Benutzeravatar
hikaru
Beiträge: 10725
Registriert: 09.04.2008 12:48:59

Re: gehört Chromium nach non-free?

Beitrag von hikaru » 07.02.2017 23:13:15

Von den Dateien die im Bugreport aufgelistet wurden sind noch diese 7 übrig:

Code: Alles auswählen

third_party/analytics/google-analytics-bundle.js
third_party/dom_distiller_js/dist/js/domdistiller_wrapped.js
third_party/dom_distiller_js/dist/js/domdistiller.js
third_party/web-animations-js/sources/web-animations.min.js
third_party/web-animations-js/sources/web-animations-next.min.js
third_party/web-animations-js/sources/web-animations-next-lite.min.js
ui/webui/resources/js/jstemplate_compiled.js
Wie von rendegast angemerkt enthalten die ersten sechs Dateien Code, der automatisch generiert aussieht (z.B. [1]). Wie kam der Code zustande und was macht der?

Das letzte jstemplate_compiled.js hat diesen Inhalt:

Code: Alles auswählen

// Copyright (c) 2012 The Chromium Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

// This file serves as a proxy to bring the included js file from /third_party
// into its correct location under the resources directory tree, whence it is
// delivered via a chrome://resources URL.  See ../webui_resources.grd.
<include src="../../../../third_party/jstemplate/jstemplate_compiled.js">
Das hier erwähnte Include ist wieder so eine kryptische, nach automatischer Generierung aussehende Javascript-Codewüste.

Was macht man nun damit? Ist das wirklich Freie Software im Sinne der DFSG?
Anders gefragt: Kann sich einer der Javascript-Experten hier im Forum mit vertretbarem Aufwand einen Reim auf den "Code" machen?


[1] http://sources.debian.net/src/chromium- ... bundle.js/

Benutzeravatar
TRex
Moderator
Beiträge: 6262
Registriert: 23.11.2006 12:23:54
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: KA

Re: gehört Chromium nach non-free?

Beitrag von TRex » 07.02.2017 23:24:33

Unwahrscheinlich.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nichtDon't break debian!

Benutzeravatar
hikaru
Beiträge: 10725
Registriert: 09.04.2008 12:48:59

Re: gehört Chromium nach non-free?

Beitrag von hikaru » 08.02.2017 00:22:10

rendegast hat geschrieben:*.so oder *.swf finden sich nicht mehr.
Aber

Code: Alles auswählen

# cat chromium-56.0.2924.76.filetype-split | egrep -v "ASCII text|Unicode text|PNG image data|XML document|SPEC$| text$|empty$|MS Windows icon|SVG Scalab|Ogg data|PDF docum|RIFF|HTML docum|data$|SQLite |XML 1.0 docu|ISO-8859 text|UTF-8 Unicode|Java serialization|symbolic link|MSVC progr" | wc -l
800
darunter noch etliche *.exe und PE32, ELF-64/32, JVT NAL sequence und mp4 Mediendateien und weitere Bildchen, *.jar, einige *.dll und wohl auch nicht wenige 'file'-Fehlerkennungen.
Was davon noch nach Anwendung des debian-Patcharchivs übrigbleibt?
Alles:

Code: Alles auswählen

$ ls -ld /tmp/chromium-*55.0.2883.75
drwxr-xr-x 58 hikaru hikaru 1480 Dez  2 00:03 /tmp/chromium-55.0.2883.75          # tar entpackt ohne Patches
drwxr-xr-x 60 hikaru hikaru 1520 Feb  7 23:58 /tmp/chromium-browser-55.0.2883.75  # tar entpackt mit Patches (apt-get source)
$ find /tmp/chromium-55.0.2883.75 -exec file '{}' \; > /tmp/chromium-56.0.2924.76.filetype-split.1
$ find /tmp/chromium-browser-55.0.2883.75 -exec file '{}' \; > /tmp/chromium-56.0.2924.76.filetype-split.2
$ diff -u0 /tmp/chromium-56.0.2924.76.filetype-split.1 /tmp/chromium-56.0.2924.76.filetype-split.2 | egrep -v "ASCII text|Unicode text|PNG image data|XML document|SPEC$| text$|empty$|MS Windows icon|SVG Scalab|Ogg data|PDF docum|RIFF|HTML docum|data$|SQLite |XML 1.0 docu|ISO-8859 text|UTF-8 Unicode|Java serialization|symbolic link|MSVC progr|@@|directory"
--- chromium-56.0.2924.76.filetype-split.1	2017-02-07 23:45:59.391296003 +0100
+++ chromium-56.0.2924.76.filetype-split.2	2017-02-08 00:08:43.893206362 +0100

Benutzeravatar
novalix
Beiträge: 1731
Registriert: 05.10.2005 12:32:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: elberfeld

Re: gehört Chromium nach non-free?

Beitrag von novalix » 08.02.2017 01:07:22

Der Code, den Du verlinkt hast, ist "minified". Alle für die Maschine unnötigen Whitespaces und Zeilenumbrüche sind entfernt. Außerdem ist er wohl auch "uglyfied". Funktions- und Variablennamen sind verkürzt (mangled). Ansonsten ist das halt der Quellcode, prinzipiell[1] lesbar und veränderbar, wenn auch kaum verstehbar[2].
MIT und BSD-Style Lizenzen sind üblicherweise DFSG kompatibel.

[1] Dass es keine wirklich glückliche Grundlage für weitere Arbeit an dem Code ist, versteht sich. Üblicherweise gibt es in JavaScript-Projekten auch zwei Versionen einer Bibliothek im Repository: die Arbeitskopie und die verkleinerte, dazu ggf. noch ein Hinweis darüber, wie die verkleinerte erstellt werden kann.
[2] Es gibt auch Tools, die das verunstalten des Codes wieder rückgängig machen. Z.B. https://github.com/beautify-web/js-beautify
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.

Benutzeravatar
hikaru
Beiträge: 10725
Registriert: 09.04.2008 12:48:59

Re: gehört Chromium nach non-free?

Beitrag von hikaru » 08.02.2017 01:18:31

novalix hat geschrieben:Ansonsten ist das halt der Quellcode, prinzipiell[1] lesbar und veränderbar, wenn auch kaum verstehbar[2].
"Prinzipiell" kann ich auch Assembler- oder gar Byte-Code lesen und verändern, aber eben kaum verstehen. Warum sollte man da bei maschnell durchgewürgtem JS-Code andere Maßstäbe an den Quellcode ansetzen?
novalix hat geschrieben:[2] Es gibt auch Tools, die das verunstalten des Codes wieder rückgängig machen. Z.B. https://github.com/beautify-web/js-beautify
Sowas funktioniert nur formal (Code-Formatierung), aber nicht inhaltlich (Kommentare,sinnvolle Variablennamen).
Der dokumentierte Gedankengang des Originalautors lässt sich damit nicht wiederherstellen.

BenutzerGa4gooPh

Re: gehört Chromium nach non-free?

Beitrag von BenutzerGa4gooPh » 08.02.2017 07:29:07

Danke Jungs für eure Mühe um Open Oource! Ich verstehe leider nicht alles - aber es geht doch mittlerweile darum, dass
Chromium-Quelltexte teilweise nicht vorhanden bzw. absichtlich zurückgestutzt sind, dass deren Funktion keiner mehr verstehen kann oder besser soll?! Zurückstutzen von Quelltext (Varaiblennamen, Kommentare) ist ja völlig unnötig für die Maschine, die mit kompiliertem Maschinencode arbeitet - aber Zusatzaufwand der Coder mit dem Ziel des Unverständnisses derjenigen, die nicht im Besitz des ausführlichen Quelltextes sind. Nur um notgedrungen Opensource-Richtlinien zu erfüllen, sein "Zeuch" dort unterzubringen. Erfüllt doch (fast) den Tatbestand des Betruges - im Gegensatz zu Closed Sources. Richtig verstanden? Und wenn ich das lese, wird mir übel:

Code: Alles auswählen

third_party/analytics/google-analytics-bundle.js
Sagt mal kurz zwischendurch was in einfachen Worten für Nichtprogrammierer, anndere sind auch am Thema interessiert. :wink:

Benutzeravatar
novalix
Beiträge: 1731
Registriert: 05.10.2005 12:32:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: elberfeld

Re: gehört Chromium nach non-free?

Beitrag von novalix » 08.02.2017 12:09:24

Das Problem liegt in den Build-Systemen für JavaScript. Üblicherweise werden komplexere Projekte dadurch funktional optimiert. Einerseits um Bandbreite im Übertragungskanal zu sparen und andererseits um der Laufzeitumgebung einen optimierten AST für performantere Umsetzung anzubieten.
Beim hier diskutierten Beispiel findet man den Quellcode in diesem Repo: https://github.com/GoogleChrome/chrome- ... -analytics
Die Datei https://github.com/GoogleChrome/chrome- ... -bundle.js ist das Ergebnis des Build-Prozesses mittels Google Closure Compiler.
Offensichtlich ist die gesamte Kette freie Software im Sinne der DFSG.
Die Frage ist, ob Debian zusätzlich zu den jeweiligen gebündelten, optimierten Quellen noch die eigentlichen Quelldateien und die gesamte jeweilige Build-Chain mitliefern muss.
Dazu gibt es schon so einiges an Diskussion, z.B. Debian Bugreport673727, Debian Bugreport817092 und Debian Bugreport830978.
Alles nicht so ganz einfach eindeutig zu beantworten, wie ich finde.

Hypothetisches Beispiel (hinkt gewaltig):
Du entwickelst eine quelloffene Anwendung in der Du das UI aufhübschst indem Du Mandelbrot-Mengen als Hintergrundbilder einbindest. Die png dafür stellst Du unter eine freie Lizenz und erstellst sie mit einer anderen Software auf Deinem Rechner. Weil Du Bock darauf hast, koppelst Du in Deiner Entwicklungsumgebung die Erstellung dieser png an die Commit Messages Deiner Bearbeitungen via git-hook o. ä.
So lange die Bilder unter einer freien Lizenz stehen, würde wohl keiner von Dir sinnvoll verlangen können, die Build-Chain der png offen zu legen und mit zu liefern.

NB: Die Frage, ob der Inhalt von Dateien verständlich ist oder nicht, ist ein eher kniffeliges Kriterium.
Eine .asm ist Quellcode, auch wenn sie kaum einer versteht. Dokumentation von Quellcode ist keine Voraussetzung, um diesen als frei zu kategorisieren.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.

Benutzeravatar
hikaru
Beiträge: 10725
Registriert: 09.04.2008 12:48:59

Re: gehört Chromium nach non-free?

Beitrag von hikaru » 08.02.2017 13:17:53

novalix hat geschrieben:Das Problem liegt in den Build-Systemen für JavaScript. Üblicherweise werden komplexere Projekte dadurch funktional optimiert. Einerseits um Bandbreite im Übertragungskanal zu sparen und andererseits um der Laufzeitumgebung einen optimierten AST für performantere Umsetzung anzubieten.
Dagegen ist ja auch nichts einzuwenden, wenn es um die ausgeführten "Binaries" geht. Aber hier geht es doch um Quellcode. Und da hat minified JS mMn nichts zu suchen.
novalix hat geschrieben:Beim hier diskutierten Beispiel findet man den Quellcode in diesem Repo: https://github.com/GoogleChrome/chrome- ... -analytics
Die Datei https://github.com/GoogleChrome/chrome- ... -bundle.js ist das Ergebnis des Build-Prozesses mittels Google Closure Compiler.
Offensichtlich ist die gesamte Kette freie Software im Sinne der DFSG.
Aber eben nur als vollständige Kette. Schneide ich den vorderen Teil ab, dann wird der Hintere mMn genauso DFSG-unfrei, wie ein compiliertes C-Programm zu dem ich den Quellcode nicht anbiete. Dass der eigentliche Quellcode nur bei Upstream und nicht bei Debian vorliegt erscheint mir nicht ok, sonst könnte Debian sein ganzes Quellarchiv einstampfen und nur noch auf Upstream verweisen, was hinsichtlich der Reproduzierbarkeit natürlich eine Katastrophe wäre.
novalix hat geschrieben:Die Frage ist, ob Debian zusätzlich zu den jeweiligen gebündelten, optimierten Quellen noch die eigentlichen Quelldateien und die gesamte jeweilige Build-Chain mitliefern muss.
Dazu gibt es schon so einiges an Diskussion, z.B. Debian Bugreport673727, Debian Bugreport817092 und Debian Bugreport830978.
Alles nicht so ganz einfach eindeutig zu beantworten, wie ich finde.
Ich finde hier Debian Bugreport817092 und die ersten 50% (den Rest, der dann eher organisationsphilosophisch wird, habe ich noch nicht gelesen) von Debian Bugreport830978 recht eindeutig kontra minified JS. Aus Debian Bugreport673727 mag ich kein Fazit ziehen. Aber mein Eindruck mag nur Confirmation Bias sein.
novalix hat geschrieben:NB: Die Frage, ob der Inhalt von Dateien verständlich ist oder nicht, ist ein eher kniffeliges Kriterium.
Eine .asm ist Quellcode, auch wenn sie kaum einer versteht. Dokumentation von Quellcode ist keine Voraussetzung, um diesen als frei zu kategorisieren.
Stimmt! Aber offenbar gibt es ein formal besseres Kriterium das inhaltlich auf das Selbe hinausläuft:
In den von dir verlinkten Bugreports wird immer wieder erwähnt, dass Quellcode in Debian im von Upstream bevorzugten Format für Patches vorliegen soll(/muss?). Ohne es geprüft zu haben vermute ich, dass minified JS kein von Google bevorzugtes Format für Chromium-Patches ist.

Benutzeravatar
novalix
Beiträge: 1731
Registriert: 05.10.2005 12:32:57
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: elberfeld

Re: gehört Chromium nach non-free?

Beitrag von novalix » 08.02.2017 15:51:07

hikaru hat geschrieben:
novalix hat geschrieben:--snip--
Offensichtlich ist die gesamte Kette freie Software im Sinne der DFSG.
Aber eben nur als vollständige Kette. Schneide ich den vorderen Teil ab, dann wird der Hintere mMn genauso DFSG-unfrei, wie ein compiliertes C-Programm zu dem ich den Quellcode nicht anbiete. Dass der eigentliche Quellcode nur bei Upstream und nicht bei Debian vorliegt erscheint mir nicht ok, sonst könnte Debian sein ganzes Quellarchiv einstampfen und nur noch auf Upstream verweisen, was hinsichtlich der Reproduzierbarkeit natürlich eine Katastrophe wäre.
Irgendwo da liegt das Problem, ja.
Zunächst mal ist es so, dass Linux-Distributionen wie Debian sehr stark auf dem Workflow von C bzw. C-artigen Sprachen aufsetzen. Die damit verbundenen Build-Systeme (Makefiles und so) einigermaßen in den Griff zu bekommen und zu warten/weiter entwickeln ist schon eine nicht zu kleine Aufgabe. Sukzessive drängen zusätzliche Programmiersprachen mit z.T. sehr unterschiedlichen Techniken der Distribution und Weiterverarbeitung in die Infrastruktur.
JavaScript, oder genauer ECMA-Script, ist in den letzten .ca 15 Jahren zu einer wirklich großen Plattform gereift, nicht zuletzt durch die Alimentation großer Entwicklergruppen durch Google, Mozilla, etc.
Debian hat zunächst einmal das rein praktische Problem, die so entstandene Infrastruktur in seine gewohnten Paketierungsprozesse zu integrieren. Man bräuchte eigentlich viel mehr Manpower, um mit der Entwicklung schritt zu halten. Das fängt aber eigentlich schon bei Plattformen wie Perl oder Python an, deren volle Möglichkeiten innerhalb der Paketinfrastruktur nur kompromissbehaftet genutzt werden können. Man hat einen Modus Vivendi gefunden.
Das die vorliegende Situation unbefriedigend ist und nicht das Ende der Fahnenstange sein darf, sehe ich auch. Allerdings ist der Vergleich mit kompilierten C-Code auch nicht richtig. Die gebündelten .js sehen scheiße aus und sind aus sich heraus kaum zu verstehen. Ich kann und darf sie aber zielgerichtet ändern, so dass der daraus generierte Byte-Code meinen Vorstellungen entspricht. Es sind Quelldateien.
Jetzt haben die Paketierungsbemühungen von JavaScript-Software bei Debian in den letzten Jahren schon deutliche Fortschritte gemacht (vor allen Dingen in der node.js Infrastruktur). Ich denke, dass sich diese Unklarheiten in den nächsten Jahren sukzessive auflösen können.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.

Benutzeravatar
hikaru
Beiträge: 10725
Registriert: 09.04.2008 12:48:59

Re: gehört Chromium nach non-free?

Beitrag von hikaru » 08.02.2017 16:10:07

novalix hat geschrieben:Allerdings ist der Vergleich mit kompilierten C-Code auch nicht richtig. Die gebündelten .js sehen scheiße aus und sind aus sich heraus kaum zu verstehen. Ich kann und darf sie aber zielgerichtet ändern, so dass der daraus generierte Byte-Code meinen Vorstellungen entspricht. Es sind Quelldateien.
Mit dieser Begründung erkläre ich ASM-Zwischencode zu "Quelldateien". ;)

wanne
Moderator
Beiträge: 6072
Registriert: 24.05.2010 12:39:42

Re: gehört Chromium nach non-free?

Beitrag von wanne » 09.02.2017 11:50:06

novalix hat geschrieben:Die gebündelten .js sehen scheiße aus und sind aus sich heraus kaum zu verstehen. Ich kann und darf sie aber zielgerichtet ändern, so dass der daraus generierte Byte-Code meinen Vorstellungen entspricht. Es sind Quelldateien.
Cool, wusste gar nicht das Visual Studio, Lotus Notes und Maple OepenSource sind. Und wie sieht das aus mit MS Office, wenn ich das durch nen disasseblerer oder gar decompiler laufen lasse? Dann habe ich ja auch wieder C-Code. Ist das dann auch OpenSource?

Quatsch das Ding ist ganz einfach: Der Quellcode ist der Code in dem Ursprünglich (von Menschen) geschrieben wurde. (Deswegen steckt da auch Quelle drin.) PUNKT. Mit dem Datenformat hat das gar nichts zu tun. Und wenn man AWT nutzt ist der Quellcode entsprechend Java und das Compilat Javascript. Nutzt man dagegen Rhino ist der Quellcode JavaScript und das Compilat Java VM-Code.
Deswegen ist john Open source obwohl es da größtenteils nur Assembler gibt, und der Nvidia-Treiber aber nicht auch wenn man da genauso das Assembler bekommt.

Die Lesbarkeit ist da nur ein Anzeichen für: Minified JS oder gigabyteweise Assembler hat offensichtlich niemand von Hand geschrieben. Deswegen verlangt man da nach dem Sourcecode. Genauso unlesbares Perl könnte aber durchaus von Menschen geschrieben worden sein. Deswegen geht man da eher von Source-Code aus. (Das ändert sich sobald man generated by xyz im Header findet.) Bilder und co sind davon btw. ausgschlossen, weil es sich nur um (nicht ausgeführte und nicht interpretierte) Daten handelt. Da ist die grenze btw. aber deutlich schwammiger. (Guckt euch mal die Bugs in dekomressions libs an.)
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
hikaru
Beiträge: 10725
Registriert: 09.04.2008 12:48:59

Re: gehört Chromium nach non-free?

Beitrag von hikaru » 09.02.2017 13:36:04

Mal ein eher organisatorischer Einwurf:
Wie bereits erwähnt, wurde Debian Bugreport787527 gegen Debianchromium-browser gerichtet. Das Binärpaket heißt inzwischen Debianchromium, weshalb der Bugreport dort nicht mehr auftaucht. [1] Allerdings taucht er nach wie vor bei chromium-browser auf. [2] Auch das Quellcode-Paket heißt nach wie vor chromium-browser. [3]

Ich würde den Report daher gern an chromium umleiten. Erzeugt aber eine Umleitung überhaupt irgendwo einen Eindruck der groß genug ist um vom Release-Team wahrgenommen zu werden oder verpufft das beim Paketbetreuer, der den Bug ja offenbar auch in den letzten 1,5 Jahren eher stiefmütterlich behandelt hat?
Die Alternative wäre, einen völlig neuen Bugreport gegen chromium zu richten und in diesem auf den ursprünglichen Bugreport zu verweisen. Die beiden würden dann natürlich von irgendwem zusammengeführt werden und würden in dem Zuge Aufmerksamkeit erzeugen. Zumindest würde zwischenzeitlich mal ein NEUER rc-Bug aufblitzen. Die Vorgehensweise wär natürlich konzeptuell hässlich, würde ich aber bevorzugen, falls es die Erfolgsaussichten auf eine erneute Beschäftigung damit erhöht.


[1] https://bugs.debian.org/cgi-bin/pkgrepo ... t=unstable
[2] https://bugs.debian.org/cgi-bin/pkgrepo ... t=unstable
[3] https://packages.debian.org/source/sid/chromium-browser

Antworten