Nabend, wie würde man diesen Fehler fachmännisch lösen? libdbus++.i586: E: shlib-policy-name-error (Badness: 10000) libdbus++-0_6_0 Your package contains a single shared library but is not named after its SONAME. In einem anderen Paket habe ich im %install Bereich manuell einen sonamen vergeben. Aber mich würde interessieren, wie würdet ihr obigen Fehler angehen? Und auch wie vergebe ich Versionsnummern für so-Files? -- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090216 13:53]:
libdbus++.i586: E: shlib-policy-name-error (Badness: 10000) libdbus++-0_6_0 ^^^^^^^^^^^^^^ Da gibt Dir rpmlint schon den Namen vor, den es zu sehen wünscht. Ergo solltest Du in libdbus++ ein Subpaket mit diesem Namen erzeugen, welches *nur* die dynamische Bibliothek sammt Symlink enthält (sprich %{_libdir}/libdbus++.so.*).
Und auch wie vergebe ich Versionsnummern für so-Files?
Die Versionsnummern werden von Bibliothek zu Bibliothek unterschiedlich gehandhabt, wobei nur wenige Projekte einen Plan zu haben scheinen, wie man sowas vernünftig handhabt. Das vernünftigste Konzept, welches mir bislang untergekommen ist findet sich in der libtool Dokumentation (info '(libtool)Versioning'). BTW, abgesehen von dem guten Konzept macht libtool IMO mehr Probleme als es löst :) Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Montag 16 Februar 2009 18:07:04 Philipp Thomas wrote:
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090216 13:53]:
libdbus++.i586: E: shlib-policy-name-error (Badness: 10000) libdbus++-0_6_0 ^^^^^^^^^^^^^^ Da gibt Dir rpmlint schon den Namen vor, den es zu sehen wünscht. Ergo solltest Du in libdbus++ ein Subpaket mit diesem Namen erzeugen, welches *nur* die dynamische Bibliothek sammt Symlink enthält (sprich %{_libdir}/libdbus++.so.*). Heißt jetzt aber sehr umständlich: libdbus++-libdbus++-0_6_0.0.6.0.rpm Gefällt mir nicht wirklich. Scheint auch nicht zu funktionieren.
Jetzt habe ich noch folgende Errors: libdbus++.i586: W: no-binary The package should be of the noarch architecture because it doesn't contain any binaries. libdbus++.i586: W: shlib-policy-missing-lib Your package starts with 'lib' as part of it's name, but does not provide any libraries. It must not be called a lib-package then. Give it a more sensible name. libdbus++.i586: W: shlib-policy-nonversioned-dir /usr/share/doc/packages/libdbus++ Your shared library package contains non-versioned directories. Those will not allow to install multiple versions of the package in parallel. libdbus++-devel.i586: W: static-library-without-debuginfo /usr/lib/libdbus++.a The static library doesn't contain any debuginfo. Binaries linking against this static library can't be properly debugged. libdbus++-libdbus++-0_6_0.i586: E: shlib-policy-name-error (Badness: 10000) libdbus++-0_6_0 Your package contains a single shared library but is not named after its SONAME. Das hängt wohl überwiegend mit der Library zusammen. *kopfkratz* Ich habe mal einen checkin in das OBS gemacht (auch wenn ich es hasse etwas unfertiges Bauen zu lassen. Kostet zuviele Resourcen), so könnt ihr auch den Bauvorgang und die aktuelle Spec nachvollziehen. dnh hat ja auch jetzt Maintainerrechte ;-) Project: home:saigkill. -- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Mon, 16 Feb 2009 22:03:28 +0100 schriebst Du:
Heißt jetzt aber sehr umständlich: libdbus++-libdbus++-0_6_0.0.6.0.rpm Gefällt mir nicht wirklich. Scheint auch nicht zu funktionieren.
Das ist ja auch Blödsinn :) Da gehört bei %package, %description und %files (also überall wo der Name angegeben werden muss) jeweils ein '-n libdbus++-0_6_0' hin Jetzt habe ich noch folgende Errors: [...] Ich schaue es mir morgen einmal an, dann kann ich mehr dazu sagen. Philipp
Das hängt wohl überwiegend mit der Library zusammen. *kopfkratz*
Project: home:saigkill.
Bitte bei sowas immer vollen Namen angeben. Ich vermute mal der ist home:saigkill/libdbus++ (gerade geprüft, es ist so :). Ich habe das Paket jetzt mal ein wenig modifiziert aber nicht geprüft, ob das so auch baut (auf der Maschine der GWDG habe ich keine root-Rechte und damit geht 'osc build' nicht). Probier mal aus, ob der "collaboration request" das tut, was er soll. Im Zweifelsfall braucht es halt noch ein rpmlintrc, mit welchem rpmlint abgewöhnt wird, über das Eine oder Andere zu meckern. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Die, 17 Feb 2009, Philipp Thomas schrieb:
Am Mon, 16 Feb 2009 22:03:28 +0100 schriebst Du: [..] Bitte bei sowas immer vollen Namen angeben. Ich vermute mal der ist home:saigkill/libdbus++ (gerade geprüft, es ist so :). Ich habe das Paket jetzt mal ein wenig modifiziert aber nicht geprüft, ob das so auch baut (auf der Maschine der GWDG habe ich keine root-Rechte und damit geht 'osc build' nicht). Probier mal aus, ob der "collaboration request" das tut, was er soll. Im Zweifelsfall braucht es halt noch ein rpmlintrc, mit welchem rpmlint abgewöhnt wird, über das Eine oder Andere zu meckern.
Ich hatte Sascha per PM mein .spec gemailt, hab jetzt noch ein paar Änderungen drin, jetzt hat rpmlint nur noch je ein 'W: checking' pro RPM zu meckern... https://build.opensuse.org/package/view_file?file=libdbus%2B%2B.spec&package=libdbus%2B%2B&project=home%3Adnh%3Atesting (Lokal heißt die Datei libdbus++-0.6.0.spec, mag ich so lieber ;) Über das oben und die Dateiliste sollte man nochmal drübergucken. Die Zeile mit dem .la in der Dateiliste hab ich mal extra dringelassen. BTW@Philipp: das hatte ich schon so, bevor ich deine Version des .spec gesehen hab -- hab auch kontrolliert, daß keine .la in den .pc Dateien drinsteht ;) Und wie man die Änderungen am configure.in / den Makefile.in macht ist mir letztlich egal, schön ist, wenn nicht das ganze autoreconf durchlaufen muß. rpmlint läuft mit der /etc/rpmlint/config und /etc/rpmlint/factory.config durch (bis auf ein "W: checking" je .rpm). Ansonsten bin ich offen für Kritik :) *hui* hab grad mal den Build angestups und guck jetzt dabei zu ... Cool :) -dnh -- Well I wish you'd just tell me rather than try to engage my enthusiasm. -- Marvin -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Di d. 17 Feb 2009 02:20:17 +0100 schriebst Du:
schön ist, wenn nicht das ganze autoreconf durchlaufen muß.
Da bin ich anderer Meinung :) Letztlich hilft nur autoreconf, configure auf dem aktuellen Stand zu halten. Ich habe zu oft erlebt, das es wegen veralteter Autoconfmakros zu Problemen kam.
Ansonsten bin ich offen für Kritik :)
Kommt schon, keine Bange :) Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Mon, 16 Feb 2009, Philipp Thomas schrieb:
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090216 13:53]:
libdbus++.i586: E: shlib-policy-name-error (Badness: 10000) libdbus++-0_6_0 ^^^^^^^^^^^^^^ Da gibt Dir rpmlint schon den Namen vor, den es zu sehen wünscht. Ergo solltest Du in libdbus++ ein Subpaket mit diesem Namen erzeugen, welches *nur* die dynamische Bibliothek sammt Symlink enthält (sprich %{_libdir}/libdbus++.so.*).
Und auch wie vergebe ich Versionsnummern für so-Files?
Die Versionsnummern werden von Bibliothek zu Bibliothek unterschiedlich gehandhabt, wobei nur wenige Projekte einen Plan zu haben scheinen, wie man sowas vernünftig handhabt. Das vernünftigste Konzept, welches mir bislang untergekommen ist findet sich in der libtool Dokumentation (info '(libtool)Versioning'). BTW, abgesehen von dem guten Konzept macht libtool IMO mehr Probleme als es löst :)
BTW: findest du es sinnvoll, daß die lib 'libdbus++-0.6.0.so' heißt? Ich hab das Spec grad mal umgebaut, so daß libdbus++.so.0.6.0 dabei rauskommt (samt passender symlinks .so.0 und .so), und daß auch die thread-safe Variante gebaut wird. Ist das sinnvoller? Vorschläge? Außerdem hab ich ein paar überflüssige BuildRequires rausgeworfen. Mit rpmlint hab ich noch Ärger: shlib-policy-missing-suffix und shlib-policy-nonversioned-dir (bezieht sich auf's docdir). Sagt Bescheid, ob ich das spec raufladen soll (libdbus++-0.6.0.spec) oder per Mail oder ... -dnh -- Yay! I have found the last bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bu%$@#$@#%$@# Error: Missing Carrier Signal -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Tue, 17 Feb 2009 01:15:27 +0100 schriebst Du:
BTW: findest du es sinnvoll, daß die lib 'libdbus++-0.6.0.so' heißt?
Bedingt. Mit der Benamsung machst Du klar, das jede Version binär inkompatibel zu jeglicher anderen Version ist. Das ist gut so, wenn die Upstream-Leute sich nicht um Rückwärtskompatibilität kümmern, die ja dann gewisse Regeln für die Versionsnummer erfordern wie z.B. Erhöhung der Major-Version bei Änderungen des ABI (also z.B. Änderungen bei den Membern einer Struktur oder den Parametern einer Funktion) So wie es aussieht, folgt die Version der Bibliothek der Version des Paketes, was IMO zeigt, das die Leute von Bibliotheksversionen nicht wirklich einen Plan haben. Schau Dir mal die Verrenkungen an, die ich bei boost betreiben musste, um da vernünftige Namen und Versionen hinzubekommen (boost.spec.in in devel:libraries:c_c++/boost).
Ich hab das Spec grad mal umgebaut, so daß libdbus++.so.0.6.0 dabei rauskommt (samt passender symlinks .so.0 und .so), und daß auch die thread-safe Variante gebaut wird.
Ist das sinnvoller? Vorschläge?
IMHO nein. Thread-safe Version ist prima und ich würde sogar soweit gehen, nur noch die zu bauen. boost.org baut seid 1.38 auch nur noch die threadsafe-Variante.
Außerdem hab ich ein paar überflüssige BuildRequires rausgeworfen.
Oh, welche?
Sagt Bescheid, ob ich das spec raufladen soll (libdbus++-0.6.0.spec) oder per Mail oder ...
Wende den collaboration request an oder schau Dir in home:psmt:branches:home:saigkill/libdbus++ an, wie ich mir das Spec vorstelle :) Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Die, 17 Feb 2009, Philipp Thomas schrieb:
Am Tue, 17 Feb 2009 01:15:27 +0100 schriebst Du:
BTW: findest du es sinnvoll, daß die lib 'libdbus++-0.6.0.so' heißt?
Bedingt. Mit der Benamsung machst Du klar, das jede Version binär inkompatibel zu jeglicher anderen Version ist. Das ist gut so, wenn die Upstream-Leute sich nicht um Rückwärtskompatibilität kümmern, die ja dann gewisse Regeln für die Versionsnummer erfordern wie z.B. Erhöhung der Major-Version bei Änderungen des ABI (also z.B. Änderungen bei den Membern einer Struktur oder den Parametern einer Funktion).
Ah, ok. ACK.
So wie es aussieht, folgt die Version der Bibliothek der Version des Paketes, was IMO zeigt, das die Leute von Bibliotheksversionen nicht wirklich einen Plan haben.
Soweit war ich auch schon ;) Meine Vermutung ist, daß sie libtools -release mit -version-number verwechselt haben (oder so) ;)
Schau Dir mal die Verrenkungen an, die ich bei boost betreiben musste, um da vernünftige Namen und Versionen hinzubekommen (boost.spec.in in devel:libraries:c_c++/boost).
*grusel* Ich hab hier (auf meiner ollen Kiste) es mit diversen gcc noch nicht geschafft boost zu kompilieren (diverse Versionen, älter, aktuell)...
Ich hab das Spec grad mal umgebaut, so daß libdbus++.so.0.6.0 dabei rauskommt (samt passender symlinks .so.0 und .so), und daß auch die thread-safe Variante gebaut wird.
Ist das sinnvoller? Vorschläge?
IMHO nein.
Also lieber die libdbus++-0.6.0.so Variante, odr? Ok, darum kann ich mich kümmern (morgen). Ich mags aber eher nicht.
Thread-safe Version ist prima und ich würde sogar soweit gehen, nur noch die zu bauen. boost.org baut seid 1.38 auch nur noch die threadsafe-Variante.
Auch ne Idee.
Außerdem hab ich ein paar überflüssige BuildRequires rausgeworfen.
Oh, welche?
libtinyxml0[-devel], cmake, libxml2, libxml2-devel Bei dbus-1-glib-devel bin ich nicht sicher (Fehler auf x86_64).
Sagt Bescheid, ob ich das spec raufladen soll (libdbus++-0.6.0.spec) oder per Mail oder ...
Wende den collaboration request an oder schau Dir in home:psmt:branches:home:saigkill/libdbus++ an, wie ich mir das Spec vorstelle :)
Rel. ähnlich ;) URL zu meinem .spec nebenan ;) -dnh -- my other signature is more intellectual -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Die, 17 Feb 2009, David 'Ingrid' Haller schrieb:
Am Die, 17 Feb 2009, Philipp Thomas schrieb:
Am Tue, 17 Feb 2009 01:15:27 +0100 schriebst Du: [..]
Außerdem hab ich ein paar überflüssige BuildRequires rausgeworfen.
Oh, welche?
libtinyxml0[-devel], cmake, libxml2, libxml2-devel
Bei dbus-1-glib-devel bin ich nicht sicher (Fehler auf x86_64).
Dafür hat 'doxygen' gefehlt. -dnh -- Dann denk ich immer, "Die is genauso gespannt was sie gleich sagen wird, wie ich". Und weil sie meistens ja nichts sagen will, weil sie sich auf keinen Fall festlegen will, dann fängt sie erstmal an, so ein paar Sprechblasen abzusondern. -- Volker Pispers, "Bis neulich" (2007), über Merkel -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Die, 17 Feb 2009, David Haller schrieb:
Am Die, 17 Feb 2009, David 'Ingrid' Haller schrieb:
Am Die, 17 Feb 2009, Philipp Thomas schrieb:
Am Tue, 17 Feb 2009 01:15:27 +0100 schriebst Du: [..]
Außerdem hab ich ein paar überflüssige BuildRequires rausgeworfen.
Oh, welche?
libtinyxml0[-devel], cmake, libxml2, libxml2-devel
Bei dbus-1-glib-devel bin ich nicht sicher (Fehler auf x86_64).
Dafür hat 'doxygen' gefehlt.
So, hab jetzt nochmal umgebaut. Seltsamerweise scheitert configure ohne dbus-1-glib-devel, obwohl nix aus dem Paket (11.1) im verwendet wird. Irgendwie stimmt da was im BS nicht. Ansonsten guckt euch das .spec mal an ;) Den Paketnamen kann man ja noch ändern. https://build.opensuse.org/package/show?package=libdbus%2B%2B&project=home%3Adnh%3Atesting -dnh -- Die Asylbewerberzahlen lägen auf zu hohem Niveau und zu hohes Niveau möchte sich Herr Kanther nicht nachsagen lassen. -- Friedrich Küppersbusch -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Dienstag 17 Februar 2009 20:30:34 David Haller wrote:
Hallo,
Am Die, 17 Feb 2009, David Haller schrieb:
Am Die, 17 Feb 2009, David 'Ingrid' Haller schrieb:
Am Die, 17 Feb 2009, Philipp Thomas schrieb:
Am Tue, 17 Feb 2009 01:15:27 +0100 schriebst Du:
[..]
Außerdem hab ich ein paar überflüssige BuildRequires rausgeworfen.
Oh, welche?
libtinyxml0[-devel], cmake, libxml2, libxml2-devel
Bei dbus-1-glib-devel bin ich nicht sicher (Fehler auf x86_64).
Dafür hat 'doxygen' gefehlt.
So, hab jetzt nochmal umgebaut. Seltsamerweise scheitert configure ohne dbus-1-glib-devel, obwohl nix aus dem Paket (11.1) im verwendet wird. Irgendwie stimmt da was im BS nicht.
Ansonsten guckt euch das .spec mal an ;) Den Paketnamen kann man ja noch ändern. Hmm. Also ich finde, es sieht sauber aus. Wieso kommt bei dir nicht die RPMLint Meldung, dass der Name des Paketes $NAME_0_6_0 sein soll? -- Sincereley yours
Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Die, 17 Feb 2009, Sascha 'saigkill' Manns schrieb:
On Dienstag 17 Februar 2009 20:30:34 David Haller wrote: [..]
So, hab jetzt nochmal umgebaut. Seltsamerweise scheitert configure ohne dbus-1-glib-devel, obwohl nix aus dem Paket (11.1) im verwendet wird. Irgendwie stimmt da was im BS nicht.
Ansonsten guckt euch das .spec mal an ;) Den Paketnamen kann man ja noch ändern. Hmm. Also ich finde, es sieht sauber aus.
*g* Mal warten, was Philipp meint (wg. extra Paket oder sowas).
Wieso kommt bei dir nicht die RPMLint Meldung, dass der Name des Paketes $NAME_0_6_0 sein soll?
Wohl wg. der 0 am Ende des Paketnamens 'libdbus++0' ;) -dnh -- 102: Code Reuse (cat a.out_header; cat) > a.out (Enno Rehling) -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Dienstag 17 Februar 2009 21:58:25 David Haller wrote:
Hallo,
Am Die, 17 Feb 2009, Sascha 'saigkill' Manns schrieb:
On Dienstag 17 Februar 2009 20:30:34 David Haller wrote:
[..]
So, hab jetzt nochmal umgebaut. Seltsamerweise scheitert configure ohne dbus-1-glib-devel, obwohl nix aus dem Paket (11.1) im verwendet wird. Irgendwie stimmt da was im BS nicht.
Ansonsten guckt euch das .spec mal an ;) Den Paketnamen kann man ja noch ändern.
Hmm. Also ich finde, es sieht sauber aus. Habs mal gerade auf dem OBS probiert. 11.1 klappt gut, Factory muss ich mal schaun. Er wartet noch auf ein anderes Paket. Aber 11.0 klappt nicht. Da schmiert er ziemlich am Anfang ab: appending configuration tag "F77" to libtool checking for main in -lstdc++... yes checking for main in -lboost_date_time... yes checking for main in -lboost_signals... yes checking for main in -lboost_thread... no configure: error: *** required in order to compile this package
-- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Mit, 18 Feb 2009, Sascha 'saigkill' Manns schrieb:
On Dienstag 17 Februar 2009 21:58:25 David Haller wrote:
Hallo,
Am Die, 17 Feb 2009, Sascha 'saigkill' Manns schrieb:
On Dienstag 17 Februar 2009 20:30:34 David Haller wrote:
[..]
So, hab jetzt nochmal umgebaut. Seltsamerweise scheitert configure ohne dbus-1-glib-devel, obwohl nix aus dem Paket (11.1) im verwendet wird. Irgendwie stimmt da was im BS nicht.
Ansonsten guckt euch das .spec mal an ;) Den Paketnamen kann man ja noch ändern.
Hmm. Also ich finde, es sieht sauber aus. Habs mal gerade auf dem OBS probiert. 11.1 klappt gut, Factory muss ich mal schaun. Er wartet noch auf ein anderes Paket. Aber 11.0 klappt nicht. Da schmiert er ziemlich am Anfang ab: appending configuration tag "F77" to libtool checking for main in -lstdc++... yes checking for main in -lboost_date_time... yes checking for main in -lboost_signals... yes checking for main in -lboost_thread... no configure: error: *** required in order to compile this package
Das liegt am BuildRequires: libboost_thread1_36_0 Das gibt's in der 11.0 nicht. Da beißt einen diese Art der Versionierung. Philipp!! *HEUL* Warum gibt's da kein Meta-Provide ("boost_thread" o.ä.), über das man die lib reinziehen kann? So muß man für jeden Target raussuchen, welche boost_thread vorhanden ist und die über Versionsabfragen einbauen. *jaul* Hat mir mal einer einen Fisch für die Boost Entwickler, die anscheinend ihre Lib nicht normal versionieren können, so daß man einfach ein 'libboost_thread >= 1.x.y' verwenden könnte? Ich hab jetzt jedenfalls keine Lust die Pakete rauszusuchen. @Philipp: weißt du, ob und falls ja wie, man an das config.log eines OBS Laufs kommt? -dnh, grummelnd -- Hm, mich hat Frust in meiner Linuxanfangszeit doch eher beflügelt, ich hab mir gedacht, dem Schrotthaufen Code zeig ich mal, wer die Hosen anhat. Wobei, ich zappel wohl hier immer noch eher in einem Strampelanzug herum ;) -- Thorsten von Plotho-Kettner in suse-linux -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Mit, 18 Feb 2009, David 'Ingrid' Haller schrieb:
Am Mit, 18 Feb 2009, Sascha 'saigkill' Manns schrieb: [..]
checking for main in -lboost_thread... no configure: error: *** required in order to compile this package
Das liegt am
BuildRequires: libboost_thread1_36_0
Das gibt's in der 11.0 nicht.
Da beißt einen diese Art der Versionierung.
Philipp!! *HEUL*
Und wieso zieht boost-devel bei der 11.1 offenbar libboost_thread mit rein, aber nicht bei Factory, 11.0, 10.3 und SLE[DS]_10? -dnh -- Ed Masry: What makes you think you can just walk in there and take whatever you want? Erin Brockovich: They're called boobs, Ed. -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Mittwoch 18 Februar 2009 02:56:14 David Haller wrote:
Hallo,
Am Mit, 18 Feb 2009, David 'Ingrid' Haller schrieb:
Am Mit, 18 Feb 2009, Sascha 'saigkill' Manns schrieb:
[..]
checking for main in -lboost_thread... no configure: error: *** required in order to compile this package
Das liegt am
BuildRequires: libboost_thread1_36_0
Das gibt's in der 11.0 nicht.
Da beißt einen diese Art der Versionierung.
Philipp!! *HEUL*
Und wieso zieht boost-devel bei der 11.1 offenbar libboost_thread mit rein, aber nicht bei Factory, 11.0, 10.3 und SLE[DS]_10? So, hab jetzt boost und boost-jam (Abhängigkeit zu boost) in mein Repo verlinkt. Nun zieht er sich die Abhängigkeiten, und baut durch. Jetzt warte ich noch auf Factory, aber es sieht so aus, als wenn es klappt. Jetzt habe ich wieder 2 Pakete mehr, nur um die Abhängigkeiten zu lösen. *grrr* Es wäre schön, wenn osc Pakete aus allen Projekten laden kann. Vielleicht werde ich das mal als Feature im openFATE einbauen...
-- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090218 11:04]:
So, hab jetzt boost und boost-jam (Abhängigkeit zu boost) in mein Repo verlinkt.
Warum? Warum nicht gegen devel:libraries:c_c++ bauen wie ich es Dir auf opensuse-buildservice erklärt habe? Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Mittwoch 18 Februar 2009 17:23:18 Philipp Thomas wrote:
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090218 11:04]:
So, hab jetzt boost und boost-jam (Abhängigkeit zu boost) in mein Repo verlinkt.
Warum? Warum nicht gegen devel:libraries:c_c++ bauen wie ich es Dir auf opensuse-buildservice erklärt habe? Wieso ist das besser?
-- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090218 17:37]:
Wieso ist das besser?
Weil dann z.B. keine zusätzlichen Pakete bei der Softwaresuche auftauchen. Das Verlinken machst Du, wenn Du Änderungen an einem Paket vornehmen willst (zusätzlicher Patch oder ähnliches). Wenn Du nur Pakete aus einem anderen Projekt brauchst um Deine eigenen zu bauen ist das Bauen gegen das andee Projekt die weitaus besser Massnahme. Ausserdem hilft es ungemein dabei, die Liste der Pakete im Projekt auf das nötige Minimum zu beschränken. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Mittwoch 18 Februar 2009 19:40:21 Philipp Thomas wrote:
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090218 17:37]:
Wieso ist das besser?
Weil dann z.B. keine zusätzlichen Pakete bei der Softwaresuche auftauchen. Das Verlinken machst Du, wenn Du Änderungen an einem Paket vornehmen willst (zusätzlicher Patch oder ähnliches). Wenn Du nur Pakete aus einem anderen Projekt brauchst um Deine eigenen zu bauen ist das Bauen gegen das andee Projekt die weitaus besser Massnahme. Ausserdem hilft es ungemein dabei, die Liste der Pakete im Projekt auf das nötige Minimum zu beschränken. Da gebe ich dir vollkommen Recht. Ich hab das jetzt auch mal gemacht. Die ganzen Verlinkten Pakete rausgeworfen, und dann add Repo/Advanced/was ich will. Für KDE:Qt habe ich dann 3 Repos eingefügt (11.0, 11.1 und Factory) und für devel:librarys_c_c++ auch drei. Was wird denn da noch gebaut? In den 6 Repos steht auch "Scheduled, building und finished".
-- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Mittwoch 18 Februar 2009 19:51:19 Sascha 'saigkill' Manns wrote: > On Mittwoch 18 Februar 2009 19:40:21 Philipp Thomas wrote: > > * Sascha 'saigkill' Manns (samannsml@directbox.com) [20090218 17:37]: > > > Wieso ist das besser? > > > > Weil dann z.B. keine zusätzlichen Pakete bei der Softwaresuche > > auftauchen. Das Verlinken machst Du, wenn Du Änderungen an einem > > Paket vornehmen willst (zusätzlicher Patch oder ähnliches). Wenn Du > > nur Pakete aus einem anderen Projekt brauchst um Deine eigenen zu > > bauen ist das Bauen gegen das andee Projekt die weitaus besser > > Massnahme. Ausserdem hilft es ungemein dabei, die Liste der Pakete > > im Projekt auf das nötige Minimum zu beschränken. > > Da gebe ich dir vollkommen Recht. Ich hab das jetzt auch mal gemacht. > Die ganzen Verlinkten Pakete rausgeworfen, und dann add > Repo/Advanced/was ich will. Für KDE:Qt habe ich dann 3 Repos > eingefügt (11.0, 11.1 und Factory) und für devel:librarys_c_c++ auch > drei. Was wird denn da noch gebaut? In den 6 Repos steht auch > "Scheduled, building und finished". Hmmm. Ich weiß nicht. Zwar habe ich jetzt nur meine Pakete in meinem Repository, aber dafür ist die Liste rechts ziemlich lang: * meine 11.0,11.1,Factory * devel_libraries_c_c++ 11.0,11.1,Factory * home_psmt 11.0,11.1,Factory * KDE:Qt 11.0,11.1,Factory. Und alle Referenzrepos tauchen auch im Buildmonitor auf. Kann man das nicht irgendwie anders lösen? -- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On 2009-02-18 02:37:41 +0100, David Haller wrote: <SNIP>
Das liegt am
BuildRequires: libboost_thread1_36_0
Das gibt's in der 11.0 nicht.
Da beißt einen diese Art der Versionierung.
Philipp!! *HEUL*
Warum gibt's da kein Meta-Provide ("boost_thread" o.ä.), über das man die lib reinziehen kann? So muß man für jeden Target raussuchen, welche boost_thread vorhanden ist und die über Versionsabfragen einbauen. *jaul*
Ich habe zwar nicht den ganzen Thread so ausfuehrlich verfolgt, aber was spricht dagegen einfach nur "BuildRequires: boost-devel" zu verwenden? "BuildRequires: libboost_thread1_36_0" ist eigentlich voellig ueberfluessig.
Hat mir mal einer einen Fisch für die Boost Entwickler, die anscheinend ihre Lib nicht normal versionieren können, so daß man einfach ein 'libboost_thread >= 1.x.y' verwenden könnte?
Ich hab jetzt jedenfalls keine Lust die Pakete rauszusuchen.
@Philipp: weißt du, ob und falls ja wie, man an das config.log eines OBS Laufs kommt?
Falls du es nur haben willst, wenn %configure fehlschlaegt benutze sowas wie %build ... %configure || %__cat config.log ... Ansonsten mache einen local build (osc build...) (das ist meistens einfacher um irgendwelche Fehler aufzuspueren). Marcus -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Wed, 18 Feb 2009 10:37:36 +0100 schriebst Du:
Ich habe zwar nicht den ganzen Thread so ausfuehrlich verfolgt, aber was spricht dagegen einfach nur "BuildRequires: boost-devel" zu verwenden? "BuildRequires: libboost_thread1_36_0" ist eigentlich voellig ueberfluessig.
Nicht nur überflüssig sondern falsch! libboost_thread1_36_0 enthält *nur* die dynamische Bibliothek und die nützt Dir fürs Linken überhaupt nichts denn da brauchst Du libboost_thread.so und das ist im -devel Paket. Daher kann im BuildRequires: nur boost-devel stehen, alles andere wäre falsch. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Mit, 18 Feb 2009, Marcus Hüwe schrieb:
Ich habe zwar nicht den ganzen Thread so ausfuehrlich verfolgt, aber was spricht dagegen einfach nur "BuildRequires: boost-devel" zu verwenden? "BuildRequires: libboost_thread1_36_0" ist eigentlich voellig ueberfluessig.
Genau so hatte ich es ja, aber das scheitert dann unter 10.3, 11.0 und Factory beim configure-Test auf 'main in -lboost_thread' (Siehe Sascha's Mail ein bissl weiter oben).
Falls du es nur haben willst, wenn %configure fehlschlaegt benutze sowas wie %build ... %configure || %__cat config.log ...
Ah, gut ;) Danke. -dnh -- [ls?] command not found? [..] Das ist ein kleiner Ludwig, gefolgt von einem kleinen Siegfried (zwei muntere Recken, die auszogen, den Drachen zu schrecken). Keine Ida, denn Burgfräulein haben in Heldenrunden nix verloren. Mach einfach mal nur ls (Ludwig-Siegfried, nicht Ida-Siegfried, das könnte unanständig werden *g*), [..] -- Philipp Zacharias in suse-linux -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
* David Haller (lists@dhaller.de) [20090218 18:51]:
Genau so hatte ich es ja, aber das scheitert dann unter 10.3, 11.0 und Factory beim configure-Test auf 'main in -lboost_thread' (Siehe Sascha's Mail ein bissl weiter oben).
Vorschlag: die Autoconf-Makros aus dem Autoconf Makro-Archiv (http://autoconf-archive.org bzw http://randspringer.de/boost/index.html für die Boost-Makros) verwenden, die ich im boost-devel 1.38 mit beigepackt habe. Damit liesse sich eine vernünftige Abfrage einbauen, welche die MT-Pakete nicht baut, wenn die Bibliothek nicht zur Verfügung steht. Wäre doch eine brauchbare Alternative, oder? Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Mit, 18 Feb 2009, Philipp Thomas schrieb:
* David Haller (lists@dhaller.de) [20090218 18:51]:
Genau so hatte ich es ja, aber das scheitert dann unter 10.3, 11.0 und Factory beim configure-Test auf 'main in -lboost_thread' (Siehe Sascha's Mail ein bissl weiter oben).
Vorschlag: die Autoconf-Makros aus dem Autoconf Makro-Archiv (http://autoconf-archive.org bzw http://randspringer.de/boost/index.html für die Boost-Makros) verwenden, die ich im boost-devel 1.38 mit beigepackt habe.
Damit liesse sich eine vernünftige Abfrage einbauen, welche die MT-Pakete nicht baut, wenn die Bibliothek nicht zur Verfügung steht.
Wäre doch eine brauchbare Alternative, oder?
Sicher die sauberste, falls man die boost_thread lib nicht anders als Abhängigkeit "reinziehen" kann. Vorhanden sein sollte sie ja. Ich hab' da heute aber keine Lust zu. ;P -dnh -- #define QUESTION ((bb) || !(bb)); // Shakespeare -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Wed, 18 Feb 2009 02:37:41 +0100 schriebst Du:
Philipp!! *HEUL*
Warum gibt's da kein Meta-Provide ("boost_thread" o.ä.), über das man die lib reinziehen kann?
Weil ich es bisher nicht vorgesehen habe? Aber ich sollte tatsächlich mal darüber nachdenken.
Hat mir mal einer einen Fisch für die Boost Entwickler, die anscheinend ihre Lib nicht normal versionieren können, so daß man einfach ein 'libboost_thread >= 1.x.y' verwenden könnte?
Die Boost-Entwickler pfeifen auf ABI-Kompatibilität (das Gros verwendet wohl Windows) und eine brauchbare Namensgebung. Ursprünglich hatte das Namen wie libboost_thread-1_36_0-gcc34-mt.so.1.36.0 und der Soname war identisch! Da habe ich dann eine Rpmlint-Warnung bekommen die mich sehr erheiterte. Sinngemäss "Der Paketname überschreitet die für Joliet-Dateisysteme zulässige Länge von 64 Zeichen" :)
@Philipp: weißt du, ob und falls ja wie, man an das config.log eines OBS Laufs kommt?
Keine Ahnung. Ich würde einfach lokal bauen mit "osc build", dann hat man alles was man möchte. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
* David Haller (lists@dhaller.de) [20090217 21:59]:
Wohl wg. der 0 am Ende des Paketnamens 'libdbus++0' ;)
Entschuldigung, aber der Name libdbus++0.spec ist Blödsinn. Das Spec-File sollte IMO so heissen wie das Projekt, wobei es völlig in Ordnung ist, das kein Paket mit gleichem Namen gebaut wird. Ansonsten darfst Du das spec und .changes umbenennen, wenn libdbus++ auf Version 1.x geht. Da ist es sehr viel einfacher, nur das Subpaket mit der shared library umzubenennen, so wie das in den meisten Paketen mit shared libraries gemacht wird. Da 'osc build' wegen des fehlenden Schlüssels für die boost 1.38 Bibliotheken nicht funktioniert, habe ich jetzt kurzfristig ein eigenes Projekt in home:psmt aufgemacht. Wenn es baut sage ich Bescheid. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo, Am Mit, 18 Feb 2009, Philipp Thomas schrieb:
* David Haller (lists@dhaller.de) [20090217 21:59]:
Wohl wg. der 0 am Ende des Paketnamens 'libdbus++0' ;)
Entschuldigung, aber der Name libdbus++0.spec ist Blödsinn. Das Spec-File sollte IMO so heissen wie das Projekt, wobei es völlig in Ordnung ist, das kein Paket mit gleichem Namen gebaut wird. Ansonsten darfst Du das spec und .changes umbenennen, wenn libdbus++ auf Version 1.x geht.
Äh, mit meine .specs heißen %{name}-%{version}.spec ;)
Da ist es sehr viel einfacher, nur das Subpaket mit der shared library umzubenennen, so wie das in den meisten Paketen mit shared libraries gemacht wird.
Um ehrlich zu sein ist mir das letztlich egal ;) -dnh -- "What, you don't think "insmod emacs" is a good idea?" -- Joe Moore -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
participants (5)
-
David Haller -
Marcus Hüwe -
Philipp Thomas -
Philipp Thomas -
Sascha 'saigkill' Manns