Wie hoch sind eigentlich die Chancen das Canoncial mal den Hintern hoch bekommt um den Bug zu beheben?
kleines Projekt: mit Paketverwaltung die schily-cdrtools neben cdrkit ohne Konflikte instalieren
Anmeldungsdatum: Beiträge: 4784 |
|
Anmeldungsdatum: Beiträge: 178 |
Weist Du denn warum die letzten Pakete nicht funktioniert haben? Die cdrtools-3.0-final wird Ende Mai oder Anfang Juni kommen und zur Zeit sind keine Probleme bekannt. Es fehlt nur noch der Code der nötig ist falls man eine der seltenen nicht ab Werk formatierten BD-RE Medien bekommt. Wenn Du Probleme hast die nicht aus der Paketierung herrühren, dann solltest Du sie schnellstens melden. Achja: zum optimalen Kompilieren für das Erstellen von Debian Paketen: smake DEFUMASK=022 INS_BASE=/usr INS_RBASE=/ DESTDIR=/home/DU/debian/packages/schilyutils-test/ MANDIR=share/man install CCOM=gcc RUNPATH= Andere Paketsysteme erlauben viele der Parameter bei der Paketisierung anzugeben. |
Anmeldungsdatum: Beiträge: 178 |
Thorsten Reinbold schrieb:
Es hängt zur Zeit an Mark Shuttleworth, der sein Versprechen leider nicht eingehalten hat die cdrtools wieder in Ubuntu aufzunemhmen. Dieses Versprechen hat er mir auf der OSCON 2008 in Portland gegeben. Danach hat er sich aber leider von Leuten überreden lassen, die ihm wider besseres Wissen eingeredet haben, es gäbe Lizenzprobleme mit den cdrtools obwohl die Sun Rechtsabteilung eindeutig sagt, es gibt keine Probleme und auch der die OpenSource.org beratende Anwalt eine verallgemeinerte Aussage (mit juristischen Belegen) dazu in positiver Form abgibt. Du könntest Shuttleworth ja mal auf Dem Linux Tag in Berlin darauf ansprechen 😉 |
Anmeldungsdatum: Beiträge: 4784 |
Da bin ich leider nicht. Aber vielleicht könntest du den Infogehalt im verlinktem Bugreport etwas erhöhen? |
Anmeldungsdatum: Beiträge: 178 |
Thorsten Reinbold schrieb:
Ich habe diesen Bugreport nicht verfaßt, aber vielleicht hilft Dir meine Liste auf: http://cdrecord.berlios.de/private/linux-dist.html#problems |
Anmeldungsdatum: Beiträge: 4784 |
Nein, ich auch nicht. Hat mich aber nicht daran gehindert meinen Senf dazuzugeben. 😉 Möglicherweise würde es den Blick der Entwickler dort etwas mehr auf den Bugreport lenken, wenn du noch das ein oder andere Argument anführst. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 4532 |
schily schrieb:
meine Vermutung: PEBKAC... ich hab einfach den debian-Ordner von der grml-a58 übernommen und nur die changelog angepasst, die rules hab ich auch einfach übernommen und zu guterletzt wurde nicht mit smake übersetzt, sondern mit gnu-make. Was mit den wohl schon von Mika Prkop für Debian angepassten a58 noch ging, ging mit den original-Sourcen von dir eben nicht mehr. Um das Problem einzukreisen, hatte ich nicht mehr die Zeit. Und auch die Notwendigkeit fehlte, da die a58 bei dem Bekannten zufriedenstellend funktionieren.
ich vermute die Probleme bei mir, also bei der Paketierung ☺
ich versuchs nochmal mit den a78 und den rules, die ich schon hab, also gnu-make. Sollte das nicht funktionieren, werde ich mal versuchen eine passende rules für smake zu basteln (oder irgenwo "ausleihen"). Danke für die smake-Parameter... |
Anmeldungsdatum: Beiträge: 178 |
Thorsten Reinbold schrieb:
Die Argumente sind schon vielfach vorgebracht worden. Was has Du nicht mitbekommen und wo genau möchtest Du "weitere Argumente"? Hast Du meinen letzten Hinweis nicht gelesen? Kannst Du vielleicht kein Englisch und hast es daher nicht verstanden? |
(Themenstarter)
Anmeldungsdatum: Beiträge: 4532 |
Mahlzeit allerseits. hier sind mal neue _ungestestete_ Pakete. Dieses mal mit smake gebaut. Ich hab das smake-deb vom ppa von B.Snyder installiert, http://ppa.launchpad.net/brandonsnider/cdrtools/ubuntu/pool/main/s/smake/smake_1.2a49-0ubuntu1_i386.deb was allerdings dann beim Installieren dieser neu gebauten Pakete einen Konflikt wirft. ... Entpacke libscg1 (aus .../libscg1_2.01.01-1~a78-ubuntu1_i386.deb) ... dpkg: Fehler beim Bearbeiten von ./libscg1_2.01.01-1~a78-ubuntu1_i386.deb (--install): Versuche, »/usr/lib/profiled/libschily.a« zu überschreiben, welches auch in Paket smake ist dpkg-deb: Unterprozess paste mit Signal (Broken pipe) getötet Fehler traten auf beim Bearbeiten von: ./libscg1_2.01.01-1~a78-ubuntu1_i386.deb ... smake muss hier™ deshalb vorher deinstalliert werden. Ein Paar Files zusätzlich: debian.tar.bz2 - der Debian-Ordner, den ich zum Bauen benutze, darin die momentane rules, die eben diese Pakete ergibt. auch eine rules.gmake.old ist da dabei, die hab ich bei vorherigen Compilaten mit gmake benutzt. 0513-1835-cdrtools-a78.w.smake-log - das Log des Compiliervorgangs Edith: momentan scheint der Server zu spinnen. Ich häng das Paket später an. |
Anmeldungsdatum: Beiträge: 4784 |
schily schrieb:
Sorry, in dem Bugreport kann ich da keine lesen, auch nicht vielfach. Das ich des Englischen mächtig bin, hast du ja sicher beim lesen des von mir verlinkten Bugreports bemerkt. Antiqua: Werds später mal testen, hab gerade eklatanten Schlafmangel. 😉 |
(Themenstarter)
Anmeldungsdatum: Beiträge: 4532 |
hier das Archiv, 32-Bit |
Anmeldungsdatum: Beiträge: 178 |
Antiqua schrieb:
Das resultiert möglicherweise aus einem Konzeptproblem des Debian Paketsystems. Normale Paketsysteme gehen davon aus, daß man ein wie auch immer geartetes Gesamtsystem kompiliert und in einer Prototypdirectory mit Hilfe der Makefiles installiert und dann Dateilisten erzeugt werden mit denen die Gesamtinstallation auf mehrere Pakete verteilt werden kann bzw. auch einzelne Dateien ignoriert werden können. Die libschily gibt es komplett in cdrtools und in der gesamten "schily" Sourcesammlung in ftp://ftp.berlios.de/pub/schily/. Die "libschily", die mit smake kommt ist bewußt nicht komplett und enthält nur das was für smake benötigt wird, man sollte sie daher nicht Bestandteil eines binärpaketes machen. Achja, smake-1.2a49 ist sehr alt. Das ist eine Entwicklerversion von vor 1.2, es gibt aber bereits 1.2.1-final. Wenn Du übrigens eine Schily Sourcesammlung von ftp://ftp.berlios.de/pub/schily/ verwendest, dann wird ein aktuelles smake automatisch mit Hilfe der Bootstrapmethode kompiliert. Zu GNU-make: unter Linux sollte es eigentlich halbwegs funktionieren, denn die Parserbugs die üblicherweise Probleme bereiten wirken eigentlich nur auf DOS-ähnlichen Systemen. Allerdings gibt GNU make viele unsinnige Warnungen aus, die daraus resultieren, daß GNU make includes in Makefiles falsch bearbeitet. Es gibt allerdings einige noch nicht richtig verifizierte Fehlermeldungen nach denen GNU make einige Abhängigkeitsregeln in Makefiles komplett ignoriert wenn die -j Option verwendet wird.
Wenn ich das Log File finde werde ich es mal ansehen. Ich baue gerade daran mit der Schily Komplettsammlung weniger Warnungen von "lintian" zu bekommen. Leider sind die meisten Meldungen dieses Teils Unsinn (z.B. Meldungen über angeblich leere man pages), was es schwer macht die wirklich sinnvollen Meldungen darin zu finden. |
Anmeldungsdatum: Beiträge: 178 |
Antiqua schrieb:
Die "return value" Warnugen sind das Resultat eines GCC bugs. Im Quellcode ist in ANSI C konformer Weise vermerkt, daß der Return-Code bewußt ignoriert wird, aber ANSI C schein GCC nicht zu mögen. Die Printf Warnungen rühren daher, daß GCC nicht das %r Format kennt und vor Allem nicht weis, daß es zwei Parameter und nicht nur einen benötigt. Bei der a79 oder später wirst Du STRIPFLAGS=-s angeben können um gestripte Binaries zu installieren. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 4532 |
ich versuch gerade die a79 zu bauen und bekomme einen Fehler. die gleiche debian/rules wie zuvor bei den a78, changelog angepasst auf die neue Version im Anhang das build-Log, gebaut wie immer mit dpkg-buildpackage -rfakeroot |
Anmeldungsdatum: Beiträge: 178 |
Antiqua schrieb:
Vor 23 Jahren wurde mit SunOS-4.0 eingeführt man Pages nach /usr/share/man statt /usr/man zu packen. Nachdem dies nun faktisch alle Betriebssysteme nachgemacht haben und viele Peketierungssysteme sich darüber beschweren wenn man pages noch nach /usr/man getan werden, habe ich das letztes WE angepaßt. Da ich ohne Probleme Debian Pakete bauen konnte, gehe ich davon aus, daß Du irgendwo ein Skript hast, daß versucht die Man pages zu verschieben.... Achja, bitte füge noch STRIPFLAGS=-s bei "make install ..." hinzu und beim Kompilieren RUNPATH= |