Am Di, den 27.01.2004 schrieb Enrico Troeger um 16:52: 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) Von wo/welche -- nur falls Rückfragen entstehen. CU thl

On Tue, 27 Jan 2004 16:52:05 +0100, Enrico Troeger wrote: 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:15:40 +0100, Stefan Hoelldampf wrote: IIRC: freshrpms, dag, atrpms, ... --

Michael Schwendt wrote: 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

On Tue, 27 Jan 2004 19:47:31 +0100, Stefan Hoelldampf wrote: Teste bitte nochmal gründlich. Woher nimmt alsaconf /etc/init.d/alsa? --

Am Di, den 27.01.2004 schrieb Michael Schwendt um 21:00: 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 -- viele Grüße Martin

Michael Schwendt wrote: 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

Michael Schwendt 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. Hast Du das wirklich mit den aktuellen Paketen von freshrpms.net probiert? Regards, Stefan

On Wed, 28 Jan 2004 00:51:15 +0100, Stefan Hoelldampf wrote: Darum geht es nicht. 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. 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. --

On Wed, 28 Jan 2004 11:09:31 +0100, Alexander Dalloz wrote: 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. 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. Sollte ich das jetzt auch "bad vibrations" nennen? ;) Ich spreche nicht für fedora.us, daher geht das meiner Ansicht nach zu weit. 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. --

On Wed, 28 Jan 2004 13:56:00 +0100, Alexander Dalloz wrote: *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". Der Eindruck der Lagerbildung verhärtet sich, wenn mit Formulierungen, wie z.B. "authoritative packager", mächtig auf die virtuelle Buschtrommel geklopft wird. 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 Wed, 28 Jan 2004 16:16:52 +0100, Stefan Hoelldampf wrote: Du hast Dich durch die fedora-devel(a)fedora.us Archive gekämpft? --

On Wed, 28 Jan 2004 19:45:51 +0100, Stefan Hoelldampf wrote: :) 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 Wed, 28 Jan 2004 23:47:57 +0100, Ronny Buchmann wrote: "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) 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-] 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. 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?) Ist das der Fall? Was speziell mißfällt Dir? 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(a)wieers.com&gt; - 0.1.6-0 stable/gonvert.spec:* Wed Feb 26 2003 Dag Wieers <dag(a)wieers.com&gt; - 0.1.5-0 stable/libglademm2.spec:* Sat Mar 29 2003 Dag Wieers <dag(a)wieers.com&gt; - 2.0.1-0 stable/libgnomemm2.spec:* Sat Mar 29 2003 Dag Wieers <dag(a)wieers.com&gt; - 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. 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. 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 Thu, 29 Jan 2004 17:04:18 +0100, Ronny Buchmann wrote: 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. 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. "unterstützen" != "Aufhören, weiterhin Core oder Extras Komponenten zu upgraden" 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. Ack. Daran wird ja eifrig gearbeitet. 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. 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. 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. Wirft die Frage auf, wann sowas entdeckt würde, wenn keiner das src.rpm untersucht? ;) ?? Das baut nur ein src.rpm! Und was ist mit Abhängigkeiten? Wer baut das i386.rpm? Aber gerade "mach" setzt vernünftige Buildrequires voraus. Daran scheitern bereits massig viele Pakete! --

On Thu, 29 Jan 2004 22:48:52 +0100, Ronny Buchmann wrote: 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. Tja, nur deckt QA auch die Fälle ab, wo ein Build beim Packager läuft, aber in einer anderen Umgebung nicht. ;) "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. --