hi leute,
ich hab hier ne via82xx-onboard-soundkarte drin.
bisher lief bei mir alles sound-mäßige über arts. aber das nervt mich, weil wenn ich z.b. mit xmms musik höre, und auf stop drücke spielt er noch 2-3seks weiter (im kontrollzentrum steht bei arts "mit echtzeit-priorität...")
und auch wenn ich z.b. bzflag spiele geht sound nur wenn ich den arts deaktiviere. hab ich nun auch dauerhaft gemacht, wollte ich zum. wollte es dann mit oss probieren, funzt aber nur mit xmms(und dem entsprechenden plugin) wenn ich dann aber nen anderen sound abspielen will (z.b. über die konsole mit play), wird die ausgabe von xmms unterbrochen und nich wieder gestartet.
frage: wie bekomme ich unter fedora alsa zum laufen? die pakete sind alle installiert.
Gruß Enrico
Am Di, den 27.01.2004 schrieb Enrico Troeger um 16:52:
hi leute,
ich hab hier ne via82xx-onboard-soundkarte drin.
bisher lief bei mir alles sound-mäßige über arts. aber das nervt mich, weil wenn ich z.b. mit xmms musik höre, und auf stop drücke spielt er noch 2-3seks weiter (im kontrollzentrum steht bei arts "mit echtzeit-priorität...")
und auch wenn ich z.b. bzflag spiele geht sound nur wenn ich den arts deaktiviere. hab ich nun auch dauerhaft gemacht, wollte ich zum. wollte es dann mit oss probieren, funzt aber nur mit xmms(und dem entsprechenden plugin) wenn ich dann aber nen anderen sound abspielen will (z.b. über die konsole mit play), wird die ausgabe von xmms unterbrochen und nich wieder gestartet.
frage: wie bekomme ich unter fedora alsa zum laufen?
In die /etc/modules.conf folgendes eintragen:
------------
alias char-major-116 snd alias snd-card-0 snd-via82xx alias char-major-14 soundcore alias sound-slot-0 snd-card-0 alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss post-install snd-card-0 /usr/sbin/alsactl restore >/dev/null 2>&1 || : pre-remove snd-card-0 /usr/sbin/alsactl store >/dev/null 2>&1 || :
------------
Und die drei alten Einträge für Sound auskommentieren, diese *sollten* IIRC wie die folgende Zeilen anfangen:
alias sound-slot-0 ... post-install snd-card-0 ... post-install snd-card-0 ...
Der eigentliche Treiber ist in er zweiten Zeile (alias snd-card-0 snd-via82xx), der hier angegebene sollte der richtige sein.
Dann am besten neu starten (oder alle Sound-Applikationen beenden, alle Sound-Module entladen, /sbin/depmod -a aufrufen)
die pakete sind alle installiert.
Von wo/welche -- nur falls Rückfragen entstehen.
CU thl
Am Dienstag, 27. Januar 2004 17:19 schrieb Thorsten Leemhuis:
Am Di, den 27.01.2004 schrieb Enrico Troeger um 16:52:
hi leute,
ich hab hier ne via82xx-onboard-soundkarte drin.
bisher lief bei mir alles sound-mäßige über arts. aber das nervt mich, weil wenn ich z.b. mit xmms musik höre, und auf stop drücke spielt er noch 2-3seks weiter (im kontrollzentrum steht bei arts "mit echtzeit-priorität...")
[...]
frage: wie bekomme ich unter fedora alsa zum laufen?
In die /etc/modules.conf folgendes eintragen:
alias char-major-116 snd alias snd-card-0 snd-via82xx alias char-major-14 soundcore alias sound-slot-0 snd-card-0 alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss post-install snd-card-0 /usr/sbin/alsactl restore >/dev/null 2>&1 || : pre-remove snd-card-0 /usr/sbin/alsactl store >/dev/null 2>&1 || :
danke. werde gleich neustarten.
Und die drei alten Einträge für Sound auskommentieren, diese *sollten* IIRC wie die folgende Zeilen anfangen:
alias sound-slot-0 ... post-install snd-card-0 ... post-install snd-card-0 ...
so ähnlich. bei mir stand noch was von aumix mit drin.
Der eigentliche Treiber ist in er zweiten Zeile (alias snd-card-0 snd-via82xx), der hier angegebene sollte der richtige sein.
Dann am besten neu starten (oder alle Sound-Applikationen beenden, alle Sound-Module entladen, /sbin/depmod -a aufrufen)
die pakete sind alle installiert.
Von wo/welche -- nur falls Rückfragen entstehen.
via apt, genau von, IIRC, freshrpms
Gruß Enrico [ PartySOKe.de ]
On Tue, 27 Jan 2004 16:52:05 +0100, Enrico Troeger wrote:
frage: wie bekomme ich unter fedora alsa zum laufen? die pakete sind alle installiert.
Pakete von woher? Mit den ALSA Paketen von fedora.us rufst Du /usr/sbin/alsaconf auf, säuberst ggf. vorher Deine /etc/modules.conf von OSS Treibereinträgen (ob alsaconf das automatisch macht, hab ich nicht im Kopf gespeichert).
ALSA Pakete einiger anderer populärer Repositories sind "broken".
On Tue, 27 Jan 2004 18:58:01 +0100, Michael Schwendt wrote:
On Tue, 27 Jan 2004 18:15:40 +0100, Stefan Hoelldampf wrote:
Michael Schwendt wrote:
ALSA Pakete einiger anderer populärer Repositories sind "broken".
Welche sind das denn z.B.?
IIRC: freshrpms, dag, atrpms, ...
Streich "dag" von der Liste. Dort seh ich kein alsa-* mehr.
Michael Schwendt wrote:
ALSA Pakete einiger anderer populärer Repositories sind "broken".
Welche sind das denn z.B.?
IIRC: freshrpms, dag, atrpms, ...
Also mit den alsa-Paketen von freshrpms.net habe ich keine Probleme, wie genau sollen die denn "broken" sein?
Irgendetwas mit alsaconf kann es wohl nicht sein, denn alsa-utils-1.0.1-1.fr z.B. enthält /usr/sbin/alsaconf, was auch prima funktioniert, habe ich eben extra noch einmal getestet.
Regards, Stefan
Am Di, den 27.01.2004 schrieb Stefan Hoelldampf um 19:47:
Michael Schwendt wrote:
ALSA Pakete einiger anderer populärer Repositories sind "broken".
Welche sind das denn z.B.?
IIRC: freshrpms, dag, atrpms, ...
Also mit den alsa-Paketen von freshrpms.net habe ich keine Probleme, wie genau sollen die denn "broken" sein?
Irgendetwas mit alsaconf kann es wohl nicht sein, denn alsa-utils-1.0.1-1.fr z.B. enthält /usr/sbin/alsaconf, was auch prima funktioniert, habe ich eben extra noch einmal getestet.
Regards, Stefan
Auch ich kann über die feshrpms.net ALSA Pakete nicht klagen. Keine Probleme festgestellt. Soundkarte ist eine Soundblaster Audigy.
$ rpm -qa | grep alsa | sort alsa-driver-1.0.1-2.fr alsa-lib-1.0.1-2.fr alsa-lib-devel-1.0.1-2.fr alsaplayer-0.99.76-1.fr alsa-utils-1.0.1-1.fr gnome-alsamixer-0.9.6-2.fr kernel-module-alsa-1.0.1-2.fr_2.4.22_1.2149.nptl
Alexander
On Tue, 27 Jan 2004 20:13:07 +0100, Alexander Dalloz wrote:
Am Di, den 27.01.2004 schrieb Stefan Hoelldampf um 19:47:
Michael Schwendt wrote:
ALSA Pakete einiger anderer populärer Repositories sind "broken".
Welche sind das denn z.B.?
IIRC: freshrpms, dag, atrpms, ...
Also mit den alsa-Paketen von freshrpms.net habe ich keine Probleme, wie genau sollen die denn "broken" sein?
Irgendetwas mit alsaconf kann es wohl nicht sein, denn alsa-utils-1.0.1-1.fr z.B. enthält /usr/sbin/alsaconf, was auch prima funktioniert, habe ich eben extra noch einmal getestet.
Regards, Stefan
Auch ich kann über die feshrpms.net ALSA Pakete nicht klagen. Keine Probleme festgestellt.
Auch Du bekommst:
Loading driver... /usr/sbin/alsaconf: line 619: rcalsasound: command not found
Michael Schwendt wrote:
Auch ich kann über die feshrpms.net ALSA Pakete nicht klagen. Keine Probleme festgestellt.
Auch Du bekommst: Loading driver... /usr/sbin/alsaconf: line 619: rcalsasound: command not found
Ich bin zwar nicht Alexander, aber mit den Paketen alsa-driver-1.0.1-2.fr alsa-lib-devel-1.0.1-2.fr alsa-lib-1.0.1-2.fr alsa-utils-1.0.1-1.fr kernel-module-alsa-1.0.1-2.fr_2.4.22_1.2149.nptl bekomme ich keine Fehlermeldung, wenn ich alsaconf starte, die Konfiguration wird auch korrekt in /etc/modules.conf geschrieben.
Hast Du das wirklich mit den aktuellen Paketen von freshrpms.net probiert?
Regards, Stefan
Stefan Hoelldampf wrote:
Ich bin zwar nicht Alexander, aber mit den Paketen alsa-driver-1.0.1-2.fr alsa-lib-devel-1.0.1-2.fr alsa-lib-1.0.1-2.fr alsa-utils-1.0.1-1.fr kernel-module-alsa-1.0.1-2.fr_2.4.22_1.2149.nptl bekomme ich keine Fehlermeldung, wenn ich alsaconf starte, die Konfiguration wird auch korrekt in /etc/modules.conf geschrieben.
OK, jetzt hatte ich die "Fehler"meldung auch. Ich habe mir das freshrpms alsa-driver-src.rpm selbst nochmal übersetzt und die /etc/rc.d/init.d/alsasound mit hineinnehmen lassen.
Das Gelbe vom Ei ist alsasound aber auch nicht, wenn noch zum Beispiel das OSS-Modul "i810_audio" geladen ist, verursacht alsasound eine Endlosausgabe von etwa "device busy - cannot load module snd-intel8x0". Erst wenn man von Hand das OSS-Modul entfernt, funktioniert das automatische Laden der ALSA-Module mittels alsasound.
Für mich stellt sich jetzt die Frage, welches Verhalten mehr "broken" ist. ;-)
Regards, Stefan
On Wed, 28 Jan 2004 00:51:15 +0100, Stefan Hoelldampf wrote:
Das Gelbe vom Ei ist alsasound aber auch nicht,
Darum geht es nicht.
wenn noch zum Beispiel das OSS-Modul "i810_audio" geladen ist, verursacht alsasound eine Endlosausgabe von etwa "device busy - cannot load module snd-intel8x0". Erst wenn man von Hand das OSS-Modul entfernt, funktioniert das automatische Laden der ALSA-Module mittels alsasound.
Alsaconf ist ja auch für ALSA, nicht für OSS. :) Natürlich könnten die Entwickler versuchen, auch OSS Module zu entladen (was aber mangels generischer Namen aufwändiger wäre). Möglicherweise hatten sie wichtigeres zu tun.
Fedora Core 2 kommt möglicherweise sogar ohne alsaconf und nur mit system-config-soundcard.
Für mich stellt sich jetzt die Frage, welches Verhalten mehr "broken" ist. ;-)
Uhm, ohne alsasound initscript ließen sich in Deinem Szenario die ALSA Module ebenfalls nicht laden. Eine fehlende Datei _mit_ Fehlermeldung ist "broken", zumal es ohne alsasound richtig spaßig wird, wenn jemand mehrere audio chipsets zur Wahl hat, etwa onboard und zusätzliche Soundkarte.
Aber ist schon klar, die freshrpms Lobby sieht über solche Schnitzer hinweg. Nun bin ich mal gespannt, ob das Fehlen der Datei weiterkommuniziert wird oder ob es aus Frickel-Bequemlichkeit "deliberately broken" heißen wird.
Am Mi, den 28.01.2004 schrieb Michael Schwendt um 09:29:
On Wed, 28 Jan 2004 00:51:15 +0100, Stefan Hoelldampf wrote:
Das Gelbe vom Ei ist alsasound aber auch nicht,
Darum geht es nicht.
wenn noch zum Beispiel das OSS-Modul "i810_audio" geladen ist, verursacht alsasound eine Endlosausgabe von etwa "device busy - cannot load module snd-intel8x0". Erst wenn man von Hand das OSS-Modul entfernt, funktioniert das automatische Laden der ALSA-Module mittels alsasound.
Alsaconf ist ja auch für ALSA, nicht für OSS. :) Natürlich könnten die Entwickler versuchen, auch OSS Module zu entladen (was aber mangels generischer Namen aufwändiger wäre). Möglicherweise hatten sie wichtigeres zu tun.
Fedora Core 2 kommt möglicherweise sogar ohne alsaconf und nur mit system-config-soundcard.
Für mich stellt sich jetzt die Frage, welches Verhalten mehr "broken" ist. ;-)
Uhm, ohne alsasound initscript ließen sich in Deinem Szenario die ALSA Module ebenfalls nicht laden. Eine fehlende Datei _mit_ Fehlermeldung ist "broken", zumal es ohne alsasound richtig spaßig wird, wenn jemand mehrere audio chipsets zur Wahl hat, etwa onboard und zusätzliche Soundkarte.
Aber ist schon klar, die freshrpms Lobby sieht über solche Schnitzer hinweg. Nun bin ich mal gespannt, ob das Fehlen der Datei weiterkommuniziert wird oder ob es aus Frickel-Bequemlichkeit "deliberately broken" heißen wird.
Huh - doh! Da schwingen aber ganz schön fette 'bad vibrations' mit. Worin begründet sich diese offenbar latente Feindseeligkeit gegenüber Matthias Saous repository und seinen Nutzern? Ich hoffe doch sehr, dass sich fedora.us nicht als Hüter der einzigen und wahren Fedora RPMs jenseits vom Core sieht, sondern die Arbeit der anderen repository Betreiber zu respektieren weiß. Schließlich sind auch fedora.us Pakete nicht immer fehlerfrei.
Alexander
On Wed, 28 Jan 2004 11:09:31 +0100, Alexander Dalloz wrote:
Aber ist schon klar, die freshrpms Lobby sieht über solche Schnitzer hinweg. Nun bin ich mal gespannt, ob das Fehlen der Datei weiterkommuniziert wird oder ob es aus Frickel-Bequemlichkeit "deliberately broken" heißen wird.
Huh - doh! Da schwingen aber ganz schön fette 'bad vibrations' mit.
Nah, mitnichten "bad vibrations". ;) Eher Sarkasmus, Belustigung über den Umgang mit solchen Fehlern. Ist nicht das erste Mal. "Lobby" klingt vielleicht etwas überzogen. Das beruht auf reiner Wahrnehmung.
Worin begründet sich diese offenbar latente Feindseeligkeit gegenüber Matthias Saous repository und seinen Nutzern?
Feindseeligkeit? Wo? Eher steigende Mißachtung aufgrund von Scheinheiligkeit. Die Nutzer von freshrpms.net sind mir recht egal, sofern sie nicht die Objektivität aus den Augen verlieren.
Was Matthias Saou betrifft, er hat ursprünglich ein vernünftiges Projekt ins Leben gerufen, das einer Zielgruppe von nicht technisch versierten Red Hat Linux Nutzern verhältnismäßig bequemen Zugang zu zusätzlicher Software in RPM Form bietet. Wer sein rpmforge.net kennt (die Seite existiert noch!), den verwundert es jedoch sehr, warum Personen wie er nicht die "Geburt" eines Community Projektes, wie Fedora Linux, begeistert aufgenommen haben, das auch die Kommunikation mit den Nutzer verbessert (Stichwort Bugzilla), anstatt ausschließlich an Rahmenwerken Interesse zu zeigen, von denen das eigene Repository profitieren würde.
Aber da ich nicht mit einem eigenen Repository in Konkurrenz zu freshrpms.net oder anderen stehe, sollte das niemand überbewerten. Falls irgendwelche Fragen bestehen, dieser lieber vorher stellen.
Ich hoffe doch sehr, dass sich fedora.us nicht als Hüter der einzigen und wahren Fedora RPMs jenseits vom Core sieht,
Sollte ich das jetzt auch "bad vibrations" nennen? ;) Ich spreche nicht für fedora.us, daher geht das meiner Ansicht nach zu weit.
sondern die Arbeit der anderen repository Betreiber zu respektieren weiß. Schließlich sind auch fedora.us Pakete nicht immer fehlerfrei.
Darum geht es gar nicht. Ich bevorzuge halt das Modell eines offenen, von der Community betreuten Repositories gegenüber dem [bis auf eine Mailing Liste] geschlossenen Modell eines Repositories einer Einzelperson.
Am Mi, den 28.01.2004 schrieb Michael Schwendt um 13:24:
On Wed, 28 Jan 2004 11:09:31 +0100, Alexander Dalloz wrote:
Aber ist schon klar, die freshrpms Lobby sieht über solche Schnitzer hinweg. Nun bin ich mal gespannt, ob das Fehlen der Datei weiterkommuniziert wird oder ob es aus Frickel-Bequemlichkeit "deliberately broken" heißen wird.
Huh - doh! Da schwingen aber ganz schön fette 'bad vibrations' mit.
Nah, mitnichten "bad vibrations". ;) Eher Sarkasmus, Belustigung über den Umgang mit solchen Fehlern. Ist nicht das erste Mal. "Lobby" klingt vielleicht etwas überzogen. Das beruht auf reiner Wahrnehmung.
Ok, ich hatte den Eindruck, er würde Fehlerreports durchaus berücksichtigen, wenn auch nicht immer transparent für den Meldenden (selber mal was zum proftpd ihm gemailt ohne Rückmeldung).
Worin begründet sich diese offenbar latente Feindseeligkeit gegenüber Matthias Saous repository und seinen Nutzern?
Feindseeligkeit? Wo? Eher steigende Mißachtung aufgrund von Scheinheiligkeit. Die Nutzer von freshrpms.net sind mir recht egal, sofern sie nicht die Objektivität aus den Augen verlieren.
Was Matthias Saou betrifft, er hat ursprünglich ein vernünftiges Projekt ins Leben gerufen, das einer Zielgruppe von nicht technisch versierten Red Hat Linux Nutzern verhältnismäßig bequemen Zugang zu zusätzlicher Software in RPM Form bietet. Wer sein rpmforge.net kennt (die Seite existiert noch!), den verwundert es jedoch sehr, warum Personen wie er nicht die "Geburt" eines Community Projektes, wie Fedora Linux, begeistert aufgenommen haben, das auch die Kommunikation mit den Nutzer verbessert (Stichwort Bugzilla), anstatt ausschließlich an Rahmenwerken Interesse zu zeigen, von denen das eigene Repository profitieren würde.
Den Standpunkt kann ich nachvollziehen und die Kritik teile ich auch. Andererseits sehe ich auch den Grund, der vermutlich die große Schwelle ist, ein mittlerweile einigermaßen umfangreiches repository - "sein Baby" - möglicherweise aus den Händen zu geben, zumindest aus seiner Alleinverantwortlichkeit. Da tut er sich offensichtlich schwer oder hatte das auch nie im Sinn. Diese Einstellung kann man nur hinnehmen und eventuell sich so dazu stellen, wie du das tust - legitim!
Aber da ich nicht mit einem eigenen Repository in Konkurrenz zu freshrpms.net oder anderen stehe, sollte das niemand überbewerten. Falls irgendwelche Fragen bestehen, dieser lieber vorher stellen.
Mir war nur aufgefallen, dass du bei fedora.us RPMs mitwirkst, darum die Vermutung der "ideologischen" (vielleicht etwas irre leitender Ausdruck) Nähe.
Ich hoffe doch sehr, dass sich fedora.us nicht als Hüter der einzigen und wahren Fedora RPMs jenseits vom Core sieht,
Sollte ich das jetzt auch "bad vibrations" nennen? ;) Ich spreche nicht für fedora.us, daher geht das meiner Ansicht nach zu weit.
Nein, es war nicht so negativ gemeint/gedacht, wie das im Nachhinein klingen mag. Mein Eindruck war nur, dass sich offenbar gewisse "Lager" gebildet haben und sich möglicherweise fedora.us durch den im Fedora Projekt gemündeten "merger" privilegierter sieht.
Natürlich sehe ich die Anstrengungen und Planungen von fedora.us recht positiv, respektiere die Leistungen der anderen repository Betreiber dabei aber sehr. Das trifft sowohl auf M. Saou zu, wie auch A. Thimm und D. Wieers.
sondern die Arbeit der anderen repository Betreiber zu respektieren weiß. Schließlich sind auch fedora.us Pakete nicht immer fehlerfrei.
Darum geht es gar nicht. Ich bevorzuge halt das Modell eines offenen, von der Community betreuten Repositories gegenüber dem [bis auf eine Mailing Liste] geschlossenen Modell eines Repositories einer Einzelperson.
Ganz meine Meinung. Das Stichwort Bugzilla hast du ja schon ganz zu Recht genannt. Allerdings sehe ich die Fedora Community noch nicht entsprechend stark, um die Leistungen der bisherigen Einzelleistungen insgesamt auffangen zu können. Das wird sicher eine Weile brauchen. Debian ist auch nicht in einem halben Jahr zu dem geworden, was es heute ist (damit kein falscher Verdacht auf kommt: nein, ich bin kein Debian Fan, die Phase des "als erfahrender Linuxer muss man Debian haben" bin ich glücklicherweise hinaus:).
Michael, meine zugegeben etwas zugespitzte Replik auf deine Mail war nicht als Angriff gedacht! Ich wollte nur nachharken, um mein eigenes "Fedora Weltbild" ein bischen klarer zu gestalten.
Gruß
Alexander
On Wed, 28 Jan 2004 13:56:00 +0100, Alexander Dalloz wrote:
Mir war nur aufgefallen, dass du bei fedora.us RPMs mitwirkst, darum die Vermutung der "ideologischen" (vielleicht etwas irre leitender Ausdruck) Nähe.
*Dort* habe ich die Möglichkeit mitzuwirken. Bei freshrpms wäre ich abhängig von mail > /dev/null Symptomen und der Lust und Laune einer Einzelperson, etwas mehr Zeit für ein Paket zu opfern, als notwendig war, um einfach nur die neueste Version "herauszuhauen".
Ich hoffe doch sehr, dass sich fedora.us nicht als Hüter der einzigen und wahren Fedora RPMs jenseits vom Core sieht,
Sollte ich das jetzt auch "bad vibrations" nennen? ;) Ich spreche nicht für fedora.us, daher geht das meiner Ansicht nach zu weit.
Nein, es war nicht so negativ gemeint/gedacht, wie das im Nachhinein klingen mag. Mein Eindruck war nur, dass sich offenbar gewisse "Lager" gebildet haben und sich möglicherweise fedora.us durch den im Fedora Projekt gemündeten "merger" privilegierter sieht.
Der Eindruck der Lagerbildung verhärtet sich, wenn mit Formulierungen, wie z.B. "authoritative packager", mächtig auf die virtuelle Buschtrommel geklopft wird.
Darum geht es gar nicht. Ich bevorzuge halt das Modell eines offenen, von der Community betreuten Repositories gegenüber dem [bis auf eine Mailing Liste] geschlossenen Modell eines Repositories einer Einzelperson.
Ganz meine Meinung. Das Stichwort Bugzilla hast du ja schon ganz zu Recht genannt. Allerdings sehe ich die Fedora Community noch nicht entsprechend stark, um die Leistungen der bisherigen Einzelleistungen insgesamt auffangen zu können.
Der Schein trügt insofern, als daß die "Einzelleistungen" ungleich verteilt sind. Zu jedem geschnürten und öffentlich angebotenen Paket gehört ein Stück Verantwortung, für dieses Paket ggf. auch [Security] Fixes bereitzustellen, die Software auf Schwachstellen zu untersuchen (etwa bei Daemons oder Software, die als Superuser ausgeführt wird), neue Versionen auf veränderte Anforderungen im Paketbereich zu prüfen oder Upgrades auf Regression zu testen. Auf solche Leistungen wird auf Seiten der Individuen, die große Repositories im Alleingang verwalten, garnicht erst eingegangen. Da fragt keiner, wie es möglich ist, daß ein Packager noch am gleichen Tag ein neues Release in RPM Form anbietet oder sogar Pakete in der Core Distribution ersetzt. Und wenn einmal Nutzer nach einem Update drängen, taucht der Packager ggf. für einige Zeit unter. Es besteht ja keine Verpflichtung gegenüber den Nutzern. Nun finde aber mal jemanden, der guten Gewissens ein paar Hundert Pakete im Alleingang verwalten möchte und im Urlaub nicht fürchtet, daß (Beispiel Gaim) sich in den Paketen grausige Bugs auftun. Hier klafft eine Lücke zwischen denjenigen, die ohne Gewissensbisse einfach Pakete anbieten und denjenigen, die eher auf Arbeitsteilung hoffen und auf ein Community Project setzen, wo hoffentlich andere einspringen, wenn man selbst verhindert ist. In der öffentlichen http://fedora.us/QA queue ist es zum einen wiederholt vorgekommen, daß Pakete von anderen Repositories erst nach mehreren Korrekturen sauber und mit vorhersagbarer Konfiguration compilierten. Ebenso ist es schon öfter vorgekommen, daß ein Update während der Review-Phase nicht für gut genug befunden wurde, weil z.B. ärgerliche Bugs gefunden wurden. Dann zu sehen, wie die gleiche Software inklusiver gleicher Bugs (oder vielleicht sogar noch Paketfehlern) in einem Repository einer Einzelperson auftaucht, das schmälert die Einzelleistung ungemein. Und zu sehen, wie ein Paket lange in der Warteschlange hängt, weil niemand, der es _nach_ Veröffentlichung aber sofort installieren würde, den Mut hat, es nach einem Test abzusegnen, ist schon erbärmlich.
On Wednesday 28 January 2004 15:15, Michael Schwendt wrote:
On Wed, 28 Jan 2004 13:56:00 +0100, Alexander Dalloz wrote:
Mir war nur aufgefallen, dass du bei fedora.us RPMs mitwirkst, darum die Vermutung der "ideologischen" (vielleicht etwas irre leitender Ausdruck) Nähe.
*Dort* habe ich die Möglichkeit mitzuwirken. Bei freshrpms wäre ich abhängig von mail > /dev/null Symptomen und der Lust und Laune einer Einzelperson, etwas mehr Zeit für ein Paket zu opfern, als notwendig war, um einfach nur die neueste Version "herauszuhauen".
"etwas mehr Zeit"? Gegen "etwas" hat kaum jemand etwas, von "etwas" kann aber keine Rede sein.
Der Eindruck der Lagerbildung verhärtet sich, wenn mit Formulierungen, wie z.B. "authoritative packager", mächtig auf die virtuelle Buschtrommel geklopft wird.
Wenn du damit http://dag.wieers.com/home-made/apt/mega-merge.php meinst: das ist ein simpler Abstimmungsmechanismus zwischen den 4 großen Repositories, nicht mehr und nicht weniger.
Darum geht es gar nicht. Ich bevorzuge halt das Modell eines offenen, von der Community betreuten Repositories gegenüber dem [bis auf eine Mailing Liste] geschlossenen Modell eines Repositories einer Einzelperson.
Ganz meine Meinung. Das Stichwort Bugzilla hast du ja schon ganz zu Recht genannt. Allerdings sehe ich die Fedora Community noch nicht entsprechend stark, um die Leistungen der bisherigen Einzelleistungen insgesamt auffangen zu können.
Der Schein trügt insofern, als daß die "Einzelleistungen" ungleich verteilt sind. Zu jedem geschnürten und öffentlich angebotenen Paket gehört ein Stück Verantwortung, für dieses Paket ggf. auch [Security] Fixes bereitzustellen, die Software auf Schwachstellen zu untersuchen (etwa bei Daemons oder Software, die als Superuser ausgeführt wird), neue
Das ist zwar theoretisch richtig, aber in der fedora.us QAChecklist steht nichts von einem Code-Audit (ich halte es auch für praktisch kaum machbar)
Versionen auf veränderte Anforderungen im Paketbereich zu prüfen oder Upgrades auf Regression zu testen. Auf solche Leistungen wird auf Seiten der Individuen, die große Repositories im Alleingang verwalten, garnicht erst eingegangen. Da fragt keiner, wie es möglich ist, daß ein Packager noch am gleichen Tag ein neues Release in RPM Form anbietet oder sogar Pakete in der Core Distribution ersetzt. Und wenn einmal Nutzer nach einem Update drängen, taucht der Packager ggf. für einige Zeit unter. Es besteht
ich habe noch keinen "untertauchen" sehen
ja keine Verpflichtung gegenüber den Nutzern. Nun finde aber mal jemanden, der guten Gewissens ein paar Hundert Pakete im Alleingang verwalten möchte und im Urlaub nicht fürchtet, daß (Beispiel Gaim) sich in den Paketen grausige Bugs auftun. Hier klafft eine Lücke zwischen denjenigen, die ohne Gewissensbisse einfach Pakete anbieten und denjenigen, die eher auf Arbeitsteilung hoffen und auf ein Community Project setzen, wo hoffentlich andere einspringen, wenn man selbst verhindert ist. In der öffentlichen
fedora.us würde auch von den (bisherigen) Packagern benutzt werden, wenn der QA Prozess angemessen wäre, (davon ist er IMO weit entfernt)
Ich weiß nicht, warum an Pakete in Fedora Extras höhere Ansprüche gestellt werden sollten als an die in Core.
http://fedora.us/QA queue ist es zum einen wiederholt vorgekommen, daß Pakete von anderen Repositories erst nach mehreren Korrekturen sauber und mit vorhersagbarer Konfiguration compilierten. Ebenso ist es schon öfter vorgekommen, daß ein Update während der Review-Phase nicht für gut genug befunden wurde, weil z.B. ärgerliche Bugs gefunden wurden. Dann zu sehen, wie die gleiche Software inklusiver gleicher Bugs (oder vielleicht sogar
Es kommt wohl öfter vor, das Pakete 1:1 übernommen werden ...
noch Paketfehlern) in einem Repository einer Einzelperson auftaucht, das schmälert die Einzelleistung ungemein. Und zu sehen, wie ein Paket lange in der Warteschlange hängt, weil niemand, der es _nach_ Veröffentlichung aber sofort installieren würde, den Mut hat, es nach einem Test abzusegnen, ist schon erbärmlich.
Eine QA-Warteschlange für unstable/testing zu haben ist einfach nur krank. Da ist ja Debian noch human dagegen. Warum gibt es nicht einfach ein "qa" und ein "stable" Repository? (Als Eintrittschwelle für qa sollte rpmlint + Buildsystem reichen)
On Wed, 28 Jan 2004 23:47:57 +0100, Ronny Buchmann wrote:
On Wednesday 28 January 2004 15:15, Michael Schwendt wrote:
On Wed, 28 Jan 2004 13:56:00 +0100, Alexander Dalloz wrote:
Mir war nur aufgefallen, dass du bei fedora.us RPMs mitwirkst, darum die Vermutung der "ideologischen" (vielleicht etwas irre leitender Ausdruck) Nähe.
*Dort* habe ich die Möglichkeit mitzuwirken. Bei freshrpms wäre ich abhängig von mail > /dev/null Symptomen und der Lust und Laune einer Einzelperson, etwas mehr Zeit für ein Paket zu opfern, als notwendig war, um einfach nur die neueste Version "herauszuhauen".
"etwas mehr Zeit"? Gegen "etwas" hat kaum jemand etwas, von "etwas" kann aber keine Rede sein.
"Etwas" mehr ist aber notwendig, um Probleme entweder von vornherein zu reduzieren oder sie nachher zu beheben. Ein altes src.rpm von z.B. Red Hat Powertools zu nehmen, einen neuen source tarball einzufügen und vielleicht noch ein paar configure Parameter oder Abhängigkeiten manuell anzupassen, ist keine Leistung. Eine Leistung entsteht aus sowas erst, wenn dabei Verbesserungen vorgenommen und Schnitzer gefunden werden, Red Hat's Bugzilla System nach noch offenen Bug Reports für das Paket abgesucht wird oder auch ein Abgleich mit Debian's Paket und eventuellen Fixes darin gemacht wird. (Konfigurations- und Integrationsleistung mal außenvor gelassen)
Der Eindruck der Lagerbildung verhärtet sich, wenn mit Formulierungen, wie z.B. "authoritative packager", mächtig auf die virtuelle Buschtrommel geklopft wird.
Wenn du damit http://dag.wieers.com/home-made/apt/mega-merge.php meinst: das ist ein simpler Abstimmungsmechanismus zwischen den 4 großen Repositories, nicht mehr und nicht weniger.
Das meine ich nicht, sondern das Getöse, wenn eine Software in irgendeinem Repository schon seit Monaten als Paket angeboten wird, Nutzer sich aber erst für die neuen Pakete eines anderen Repositories interessieren und dazu Fragen stellen.
[-snip-]
Das ist zwar theoretisch richtig, aber in der fedora.us QAChecklist steht nichts von einem Code-Audit (ich halte es auch für praktisch kaum machbar)
Ein "Code-Audit" ist nicht gemeint. Und der vor wenigen Wochen unterbreitete Vorschlag, so könnten Pakete das QA System "umgehen", entbehrt jeder Grundlage, ist geradezu indiskutabel.
fedora.us würde auch von den (bisherigen) Packagern benutzt werden, wenn der QA Prozess angemessen wäre, (davon ist er IMO weit entfernt)
Wann wäre er angemessen?
(Haben nicht einige der "bisherigen Packager" verlauten lassen, daß sie nichtmal ein offizielles Fedora Extras unterstützen wollen, sondern ein "3rd party repository" bleiben wollen?)
Ich weiß nicht, warum an Pakete in Fedora Extras höhere Ansprüche gestellt werden sollten als an die in Core.
Ist das der Fall? Was speziell mißfällt Dir?
http://fedora.us/QA queue ist es zum einen wiederholt vorgekommen, daß Pakete von anderen Repositories erst nach mehreren Korrekturen sauber und mit vorhersagbarer Konfiguration compilierten. Ebenso ist es schon öfter vorgekommen, daß ein Update während der Review-Phase nicht für gut genug befunden wurde, weil z.B. ärgerliche Bugs gefunden wurden. Dann zu sehen, wie die gleiche Software inklusiver gleicher Bugs (oder vielleicht sogar
Es kommt wohl öfter vor, das Pakete 1:1 übernommen werden ...
wiederholt != öfter
Ein rekursiver "grep Saou" auf den Inhalt von allspecs.tar.gz findet gerademal 9 Pakete, die im Changelog mehrmals den Namen Matthias Saou stehen haben. Beispiel:
$ grep Wieers * -R stable/gonvert.spec:* Sat Jun 29 2003 Dag Wieers dag@wieers.com - 0.1.6-0 stable/gonvert.spec:* Wed Feb 26 2003 Dag Wieers dag@wieers.com - 0.1.5-0 stable/libglademm2.spec:* Sat Mar 29 2003 Dag Wieers dag@wieers.com - 2.0.1-0 stable/libgnomemm2.spec:* Sat Mar 29 2003 Dag Wieers dag@wieers.com - 1.3.10-0 testing/awstats.spec:- many thanks to Michael Schwendt and Dag Wieers.
;-P
Ich denke, eher wird mit bereits existierenden Paketen verglichen, ob der eigene Ansatz wohl richtig ist. Daß ein Packager ein Paket von irgendwoher nimmt und sich nicht mit dem spec Skript vertraut macht, kommt hoffentlich _nicht_ öfter vor.
noch Paketfehlern) in einem Repository einer Einzelperson auftaucht, das schmälert die Einzelleistung ungemein. Und zu sehen, wie ein Paket lange in der Warteschlange hängt, weil niemand, der es _nach_ Veröffentlichung aber sofort installieren würde, den Mut hat, es nach einem Test abzusegnen, ist schon erbärmlich.
Eine QA-Warteschlange für unstable/testing zu haben ist einfach nur krank.
Wie sollte es bei einem manuellen Build System anders aussehen? Dann hätte das Build Team nichts anderes zu tun, als Pakete abzuweisen, die vor, während oder nach der Compilierung kläglich scheitern, nichtmal funktionieren, mit falschen Dateizugriffsrechten versehen sind oder so mit manuell gesetzten Abhängigkeiten bestückt sind, daß es beim nächsten Update Problem gibt.
Ein öffentliches Community Packaging Projekt verlagert zudem leider einen Teil der Paketentwicklung in das QA System.
Anders sähe es aus, wenn der Packager ein automatisiertes Build System verwenden könnte, das sicher gegen Einbruchversuche von außen und innen ist. Aber selbst dann könnte er Pakete bauen, die mit gefährlichen oder unsinnigen Abhängigkeiten ausgestattet sind und zu Problemen führen.
Etwas für "unstable" hab ich lang nichtmehr gesehen. Das sind gerademal ein Dutzend Pakete drin. Das letzte Paket machte es am 30.November in unstable. Das war Audacity 1.2.0 pre3, vermutlich auf Wunsch des Packagers, crashte auch mit GTK2. Oder AIDE CVS Version mit Segfaults. Das Final Release hat später jemand in "testing" haben wollen.
Kommen wir zu "testing", einem Sammelplatz für development Versionen oder Pakete, die der Packager noch nicht über stable auf die Masse der Nutzer loslassen möchte. Bei fedora.us trifft man auf einen Spruch ala "good enough for testing", der besagt, daß jemand sich während der Reviewphase um technische Details gekümmert hat, aber die Stabilität zur Laufzeit oder Funktionsfähigkeit nicht großartig über mehr als einen einfachen Startversuch hinaus untersucht hat.
Aber warum sollte das QA System für testing/unstable wegfallen? Damit würde ja auch der MD5 Abgleich des Upstream Source und ein Blick in das spec Skript oder Patches wegfallen. Unverantwortlich.
Da ist ja Debian noch human dagegen. Warum gibt es nicht einfach ein "qa" und ein "stable" Repository? (Als Eintrittschwelle für qa sollte rpmlint + Buildsystem reichen)
rpmlint ist viel zu irreführend und unzuverlässig, selbst in angepaßter Version für fedora.us.
Und was mit "QA" gemeint ist, ist eben nicht wohldefiniert. Ich sehe über einige fragwürdige QA Empfehlungen lächelnd hinweg, weil ich mit Packagern zusammenarbeite, anstatt ihnen unnötig das Leben schwer zu machen, wo in meinen Augen kein Wertschöpfungspotential besteht.
On Thursday 29 January 2004 01:25, Michael Schwendt wrote:
On Wed, 28 Jan 2004 23:47:57 +0100, Ronny Buchmann wrote:
On Wednesday 28 January 2004 15:15, Michael Schwendt wrote:
On Wed, 28 Jan 2004 13:56:00 +0100, Alexander Dalloz wrote:
Mir war nur aufgefallen, dass du bei fedora.us RPMs mitwirkst, darum die Vermutung der "ideologischen" (vielleicht etwas irre leitender Ausdruck) Nähe.
*Dort* habe ich die Möglichkeit mitzuwirken. Bei freshrpms wäre ich abhängig von mail > /dev/null Symptomen und der Lust und Laune einer Einzelperson, etwas mehr Zeit für ein Paket zu opfern, als notwendig war, um einfach nur die neueste Version "herauszuhauen".
"etwas mehr Zeit"? Gegen "etwas" hat kaum jemand etwas, von "etwas" kann aber keine Rede sein.
"Etwas" mehr ist aber notwendig, um Probleme entweder von vornherein zu reduzieren oder sie nachher zu beheben. Ein altes src.rpm von z.B. Red Hat Powertools zu nehmen, einen neuen source tarball einzufügen und vielleicht noch ein paar configure Parameter oder Abhängigkeiten manuell anzupassen, ist keine Leistung. Eine Leistung entsteht aus sowas erst, wenn dabei
Mir ist es egal ob in einem spec file viel oder wenig Arbeit steckt. Mir ist auch egal ob jemand damit Ruhm erlangen will oder nicht.
fedora.us würde auch von den (bisherigen) Packagern benutzt werden, wenn der QA Prozess angemessen wäre, (davon ist er IMO weit entfernt)
Wann wäre er angemessen?
(Haben nicht einige der "bisherigen Packager" verlauten lassen, daß sie nichtmal ein offizielles Fedora Extras unterstützen wollen, sondern ein "3rd party repository" bleiben wollen?)
Es gibt durchaus gute Gründe für 3rd party repositories. Einige haben aber auch bekundet, dass sie Fedora Extras unterstützen wollen.
Ich weiß nicht, warum an Pakete in Fedora Extras höhere Ansprüche gestellt werden sollten als an die in Core.
Ist das der Fall?
Definitiv, sieh dir mal die spec files von Red Hat an, da wären schon mehrere an fedora.us gescheitert.
Was speziell mißfällt Dir?
Das Hauptproblem ist wohl momentan ein fehlendes Buildsystem. Prinzipiell halte ich es für sinnvoll, mehr oder weniger feste Maintainer für ein Paket zu haben (ohne bei jedem Release eine QA für das spec file zu machen)
Generell halte ich QA für die spec files für nicht zwingend notwendig, IMO kann man die Pakete schon für den QA Prozess per apt/yum anbieten (evtl nur SRPMS).
Dass das für die Tester ein Risiko darstellt ist mir klar, aber es ist nicht wesentlich höher als bei manuellen Download.
Mit anderen Worten: Wenn in "qa" (oder wie auch immer man das nennt) Viren, Backdoors u.s.w. drin sind, wäre mir das ziemlich egal.
Eine QA-Warteschlange für unstable/testing zu haben ist einfach nur krank.
Wie sollte es bei einem manuellen Build System anders aussehen? Dann hätte das Build Team nichts anderes zu tun, als Pakete abzuweisen, die vor, während oder nach der Compilierung kläglich scheitern, nichtmal funktionieren, mit falschen Dateizugriffsrechten versehen sind oder so mit manuell gesetzten Abhängigkeiten bestückt sind, daß es beim nächsten Update Problem gibt.
Das Problem ist hier IMO, dass an das Buildsystem zu hohe Ansprüche gestellt werden.
Mein Vorschlag: für Repository "qa": - rpmbuild -bs in mach
wenn die Pakete dann für gut befunden werden (über Bugzilla), das ganze dann auch binär (für "stable").
Ein öffentliches Community Packaging Projekt verlagert zudem leider einen Teil der Paketentwicklung in das QA System.
Anders sähe es aus, wenn der Packager ein automatisiertes Build System verwenden könnte, das sicher gegen Einbruchversuche von außen und innen ist. Aber selbst dann könnte er Pakete bauen, die mit gefährlichen oder unsinnigen Abhängigkeiten ausgestattet sind und zu Problemen führen.
s.o.
Aber warum sollte das QA System für testing/unstable wegfallen? Damit würde ja auch der MD5 Abgleich des Upstream Source und ein Blick in das spec Skript oder Patches wegfallen. Unverantwortlich.
s.o.
cu ronny
On Thu, 29 Jan 2004 17:04:18 +0100, Ronny Buchmann wrote:
Mir ist es egal ob in einem spec file viel oder wenig Arbeit steckt.
Das hat mit "viel" oder "wenig Arbeit" nichts zu tun, sondern mit Korrektheit des spec Skripts und damit verbundenem Wartungsaufwand. Ich möchte nicht ein Paket veröffentlichen, daß sich nicht deinstallieren läßt, daß mir in den post-install Skripten etwas zerschießt, daß Dateien statt in /usr/lib/foo in /usr/lib installiert, wo sie zur Laufzeit nicht gefunden werden, oder daß beim Upgrade einer Abhängigkeit das Repository zersägt, weil der Packager übereifrig manuelle Abhängigkeiten definiert hat.
Mir ist auch egal ob jemand damit Ruhm erlangen will oder nicht.
Das ist es mir in der Tat auch. Sonst würde ich nicht anderen Packagern helfen, ohne dafür in den Changelogs namentlich erwähnt zu werden.
Es gibt durchaus gute Gründe für 3rd party repositories. Einige haben aber auch bekundet, dass sie Fedora Extras unterstützen wollen.
"unterstützen" != "Aufhören, weiterhin Core oder Extras Komponenten zu upgraden"
Ich weiß nicht, warum an Pakete in Fedora Extras höhere Ansprüche gestellt werden sollten als an die in Core.
Ist das der Fall?
Definitiv, sieh dir mal die spec files von Red Hat an, da wären schon mehrere an fedora.us gescheitert.
Uhm, soll ich raten, warum? Red Hat hat ein vollkommen anderes Build System. Pakete mit unvollständigen Build Requirements versagen im Fedora.us Build System kläglich. Daher sind vollständige Buildreqs zwingend erforderlich, bevor einer vom Build Team manuell (!) dem Build System ein Paket übergibt.
Red Hats Pakete für Red Hat Linux 8.0, 9 und Fedora Core entstammen zudem nicht dem gleichen src.rpm, wie es bei fedora.us überwiegend der Fall ist. Red Hat Linux 8.0 und 9, einmal veröffentlicht, haben nicht ständig Updates gesehen, wie die Extras. Daher stammt z.B. die Anforderung nach expliziter "Epoch" in versionsbehafteten Abhängigkeiten. Andernfalls gäbe es häßliche Fälle, in denen ein Upgrade brechen könnte.
Daß spec Dateien weitestgehend bestimmt werden, ist ein Mythos. Fedora.us hat lediglich eine Schablone als Vorgabe.
Was speziell mißfällt Dir?
Das Hauptproblem ist wohl momentan ein fehlendes Buildsystem.
Ack. Daran wird ja eifrig gearbeitet.
Prinzipiell halte ich es für sinnvoll, mehr oder weniger feste Maintainer für ein Paket zu haben (ohne bei jedem Release eine QA für das spec file zu machen)
Streich das bitte aus Deinem Kopf: "QA für das spec file". Das ist nur ein Erfordernis, um erstmal in die Gänge zu kommen und brauchbare Extrapakete zu bekommen, auf die andere Pakete aufsetzen können. Aber auch, daß die Packager Erfahrung sammeln und unterstützt werden, von vornherein brauchbare Pakete zu veröffentlichen, als daß sie still und einsam nach einer Veröffentlichung ihr Paket Schritt für Schritt zurechtfrickeln. Fedora.us wäre ein Rohrkrepierer geworden, wenn es das QA System nicht geben würde. Das läßt sich ja über Bugzilla nachlesen, was da teilweise an src.rpms mit guten Gründen bemängelt wurde. Auch Sicherheitsmängel wurden teilweise gefunden und behoben. Der wichtigste Schritt während eines Reviews ist der Abgleich der source tarball Prüfsumme mit dem Upstream Projekt oder über Stichproben und Source Diffs.
Generell halte ich QA für die spec files für nicht zwingend notwendig, IMO kann man die Pakete schon für den QA Prozess per apt/yum anbieten (evtl nur SRPMS).
s.o. Das hängt davon ab, wer die Pakete erstellt. Ein src.rpm mit falschen oder schwachen Abhängigkeiten kann nach Upgrades zu einem Fremdkörper im Repository werden und weitere Upgrades erforderlich machen. Das Fedora Extras Konzept wird wohl auch vorsehen, daß nur kompetente Packager Zugriff aufs Build System bekommen und sich vorher erst einige Zeit beweisen müssen.
Dass das für die Tester ein Risiko darstellt ist mir klar, aber es ist nicht wesentlich höher als bei manuellen Download.
Doch, denn ein Paket, das im Review Repository erscheint, wird letztendlich als "Released" betrachtet und ggf. sogar von Mirrors übernommen. Im Gegensatz dazu befinden sich die src.rpms der Packager irgendwo auf privatem Webspace.
Mit anderen Worten: Wenn in "qa" (oder wie auch immer man das nennt) Viren, Backdoors u.s.w. drin sind, wäre mir das ziemlich egal.
Wirft die Frage auf, wann sowas entdeckt würde, wenn keiner das src.rpm untersucht? ;)
Das Problem ist hier IMO, dass an das Buildsystem zu hohe Ansprüche gestellt werden.
Mein Vorschlag: für Repository "qa":
- rpmbuild -bs in mach
?? Das baut nur ein src.rpm! Und was ist mit Abhängigkeiten? Wer baut das i386.rpm?
wenn die Pakete dann für gut befunden werden (über Bugzilla), das ganze dann auch binär (für "stable").
Aber gerade "mach" setzt vernünftige Buildrequires voraus. Daran scheitern bereits massig viele Pakete!
On Thursday 29 January 2004 18:38, Michael Schwendt wrote:
Mein Vorschlag: für Repository "qa":
- rpmbuild -bs in mach
?? Das baut nur ein src.rpm! Und was ist mit Abhängigkeiten? Wer baut das
eben! Ein apt-get source foo und apt-get build-dep foo sind aber angenehmer als sich durch Bugzilla zu hangeln und die Dateien manuell runterzuladen.
Ein kompletter Build sollte aber trotzdem laufen, wenn der nicht braucht man's eh nicht veröffentlichen.
wenn die Pakete dann für gut befunden werden (über Bugzilla), das ganze dann auch binär (für "stable").
Aber gerade "mach" setzt vernünftige Buildrequires voraus. Daran scheitern bereits massig viele Pakete!
Eben, da dass dann aber automatisch erkannt wird, fällt wieder ein Arbeitsschritt weg (und genau zu dem Status "nicht mehr Aufwand als zwingend nötig" will ich hin).
On Thu, 29 Jan 2004 22:48:52 +0100, Ronny Buchmann wrote:
On Thursday 29 January 2004 18:38, Michael Schwendt wrote:
Mein Vorschlag: für Repository "qa":
- rpmbuild -bs in mach
?? Das baut nur ein src.rpm! Und was ist mit Abhängigkeiten? Wer baut das
eben! Ein apt-get source foo und apt-get build-dep foo sind aber angenehmer als sich durch Bugzilla zu hangeln und die Dateien manuell runterzuladen.
Da halte ich mehr von CVS. Wenn sich der tarball nicht ändert, möchte ich den auch nicht mit jedem neuen src.rpm neu herunterladen müssen, apt-get hin und her. (bevorzuge eh noch yum) Das Hin- und Herschieben von src.rpms ist nervig, egal auf welche Weise. Desweiteren ist ein Besuch des zugehörigen Bugzilla Eintrags möglicherweise notwendig, um auf ein src.rpm vorbereitet zu sein. Auch da würdest Du nur von einem Update erfahren. Der Vorteil des Zugriffs per apt-get auf src.rpms in einer Warteschlange ist damit marginal.
Ein kompletter Build sollte aber trotzdem laufen, wenn der nicht braucht man's eh nicht veröffentlichen.
Tja, nur deckt QA auch die Fälle ab, wo ein Build beim Packager läuft, aber in einer anderen Umgebung nicht. ;)
wenn die Pakete dann für gut befunden werden (über Bugzilla), das ganze dann auch binär (für "stable").
Aber gerade "mach" setzt vernünftige Buildrequires voraus. Daran scheitern bereits massig viele Pakete!
Eben, da dass dann aber automatisch erkannt wird, fällt wieder ein Arbeitsschritt weg (und genau zu dem Status "nicht mehr Aufwand als zwingend nötig" will ich hin).
"mach" erkennt nichts automatisch. Allenfalls brechen Build Versuche ab, wenn z.B. ein configure Skript fehlende Komponenten feststellt. Was sonst noch fehlt und zu keinem Abbruch führt, müssen Packager bzw. Tester prüfen.
Michael Schwendt wrote:
Alsaconf ist ja auch für ALSA, nicht für OSS. :) Natürlich könnten die Entwickler versuchen, auch OSS Module zu entladen (was aber mangels generischer Namen aufwändiger wäre). Möglicherweise hatten sie wichtigeres zu tun.
Naja, zumindest hat alsaconf bei mir die folgenden Zeilen automatisch entfernt: alias sound-slot-0 i810_audio post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L
/dev/null 2>&1 || :
pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S
/dev/null 2>&1 || :
Uhm, ohne alsasound initscript ließen sich in Deinem Szenario die ALSA Module ebenfalls nicht laden. Eine fehlende Datei _mit_ Fehlermeldung ist "broken", zumal es ohne alsasound richtig spaßig wird, wenn jemand mehrere audio chipsets zur Wahl hat, etwa onboard und zusätzliche Soundkarte.
Aber ist schon klar, die freshrpms Lobby sieht über solche Schnitzer hinweg. Nun bin ich mal gespannt, ob das Fehlen der Datei weiterkommuniziert wird oder ob es aus Frickel-Bequemlichkeit "deliberately broken" heißen wird.
Die letzten beiden, stark von subjektiven Eindrücken geprägten Sätze lasse ich jetzt einfach mal so stehen... Warum sollte man / ich das nicht weiterkommunizieren? Für Dich scheint die Sache ja schon quasi abgestempelt zu sein.
Wer die Diskussionen um die "Interessenskonflikte" zwischen fedora.us/... und freshrpms/dag/newrpms/atrpms/... verfolgt hat, weiß ja, dass zum "Streit" immer mindestens zwei Seiten gehören. ;-)
Regards, Stefan
On Wed, 28 Jan 2004 16:16:52 +0100, Stefan Hoelldampf wrote:
Wer die Diskussionen um die "Interessenskonflikte" zwischen fedora.us/... und freshrpms/dag/newrpms/atrpms/... verfolgt hat, weiß ja, dass zum "Streit" immer mindestens zwei Seiten gehören. ;-)
Du hast Dich durch die fedora-devel@fedora.us Archive gekämpft?
Michael Schwendt wrote:
Du hast Dich durch die fedora-devel@fedora.us Archive gekämpft?
Warum sollte ich mich durch die Archive wühlen, wenn
1) ich fedora-devel@fedora.us komplett in meiner Mailbox habe? 2) das Wichtigste parallel auch über die ehemalige Liste rpm-list@freshrpms.net lief?
Regards, Stefan
On Wed, 28 Jan 2004 19:45:51 +0100, Stefan Hoelldampf wrote:
Du hast Dich durch die fedora-devel@fedora.us Archive gekämpft?
Warum sollte ich mich durch die Archive wühlen, wenn
- ich fedora-devel@fedora.us komplett in meiner Mailbox habe?
- das Wichtigste parallel auch über die ehemalige Liste rpm-list@freshrpms.net lief?
:)
Na, wenn Du den Inhalt von 1) verfolgt hast, warst Du ja auch Zeuge der diversen Querelen, die bei mir nur mehrmals ein ungläubiges Kopfschütteln veranlaßten. Ich war enttäuscht, als ich das im Nachhinein gelesen hatte.
Zu 2) kann ich mich nicht äußern. Was für Zusammenfassungen, und von wem sie kamen, dorthin x-gepostet wurden, darauf hab ich nicht geachtet.
On Tue, 27 Jan 2004 19:47:31 +0100, Stefan Hoelldampf wrote:
Michael Schwendt wrote:
ALSA Pakete einiger anderer populärer Repositories sind "broken".
Welche sind das denn z.B.?
IIRC: freshrpms, dag, atrpms, ...
Also mit den alsa-Paketen von freshrpms.net habe ich keine Probleme, wie genau sollen die denn "broken" sein?
Irgendetwas mit alsaconf kann es wohl nicht sein, denn alsa-utils-1.0.1-1.fr z.B. enthält /usr/sbin/alsaconf, was auch prima funktioniert, habe ich eben extra noch einmal getestet.
Teste bitte nochmal gründlich. Woher nimmt alsaconf /etc/init.d/alsa?
On Tue, 27 Jan 2004 20:52:20 +0100, Michael Schwendt wrote:
On Tue, 27 Jan 2004 19:47:31 +0100, Stefan Hoelldampf wrote:
Michael Schwendt wrote:
ALSA Pakete einiger anderer populärer Repositories sind "broken".
Welche sind das denn z.B.?
IIRC: freshrpms, dag, atrpms, ...
Also mit den alsa-Paketen von freshrpms.net habe ich keine Probleme, wie genau sollen die denn "broken" sein?
Irgendetwas mit alsaconf kann es wohl nicht sein, denn alsa-utils-1.0.1-1.fr z.B. enthält /usr/sbin/alsaconf, was auch prima funktioniert, habe ich eben extra noch einmal getestet.
Teste bitte nochmal gründlich. Woher nimmt alsaconf /etc/init.d/alsa?
*grummel* Zweiter Versuch:
Woher nimmt alsaconf /etc/init.d/alsasound?
Am Di, den 27.01.2004 schrieb Michael Schwendt um 21:00:
On Tue, 27 Jan 2004 20:52:20 +0100, Michael Schwendt wrote:
On Tue, 27 Jan 2004 19:47:31 +0100, Stefan Hoelldampf wrote:
Michael Schwendt wrote:
ALSA Pakete einiger anderer populärer Repositories sind "broken".
Welche sind das denn z.B.?
IIRC: freshrpms, dag, atrpms, ...
Also mit den alsa-Paketen von freshrpms.net habe ich keine Probleme, wie genau sollen die denn "broken" sein?
Irgendetwas mit alsaconf kann es wohl nicht sein, denn alsa-utils-1.0.1-1.fr z.B. enthält /usr/sbin/alsaconf, was auch prima funktioniert, habe ich eben extra noch einmal getestet.
Teste bitte nochmal gründlich. Woher nimmt alsaconf /etc/init.d/alsa?
*grummel* Zweiter Versuch:
Woher nimmt alsaconf /etc/init.d/alsasound?
Du benötigst aus dem `alsa-driver'-Tarball ein Init-Script, das leider nicht in den FreshRPMs-Paketen enthalten ist:
# cp alsa-driver-1.0.1/utils/alsasound /etc/init.d/ # /sbin/chkconfig --add alsasound
On Tue, 27 Jan 2004 21:11:40 +0100, Martin Gansser wrote:
Woher nimmt alsaconf /etc/init.d/alsasound?
Du benötigst aus dem `alsa-driver'-Tarball ein Init-Script, das leider nicht in den FreshRPMs-Paketen enthalten ist:
# cp alsa-driver-1.0.1/utils/alsasound /etc/init.d/ # /sbin/chkconfig --add alsasound
$ rpm -qf /etc/init.d/alsasound alsa-driver-1.0.1-0.fdr.6
Michael Schwendt wrote:
Irgendetwas mit alsaconf kann es wohl nicht sein, denn alsa-utils-1.0.1-1.fr z.B. enthält /usr/sbin/alsaconf, was auch prima funktioniert, habe ich eben extra noch einmal getestet.
Teste bitte nochmal gründlich. Woher nimmt alsaconf /etc/init.d/alsa?
Es gibt nur /etc/init.d/alsactl. Worauf möchtest Du hinaus? Vielleicht darauf, dass man für die Wiederherstellung der Lautstärke in der /etc/modules.conf post-install snd-card-0 /usr/sbin/alsactl restore >/dev/null 2>&1 || : pre-remove snd-card-0 /usr/sbin/alsactl store >/dev/null 2>&1 || : benötigt?
Ich habe einmal spaßeshalber alle aktuellen alsa-* und kernel-module-alsa-* Pakete von fedora.us heruntergeladen, die offensichtlich alle keine Datei /etc/init.d/alsa bzw. /etc/rc.d/init.d/alsa enthalten.
Regards, Stefan
de-users@lists.fedoraproject.org
-
Alexander Dalloz -
Enrico Troeger -
Martin Gansser -
Michael Schwendt -
Ronny Buchmann -
Stefan Hoelldampf -
Thorsten Leemhuis