PKGSRC-RELEASE ist scheinbar doch nicht so stabiel...

Yoda

[Linux|FreeBSD] - User
Hi Leute,
ich arbeite seit einiger Zeit daran mein Scource-Aktuallisierung (src, xsrc und pkgsrc) zu automatisieren. Dazu verwende ich nur die Release-Versionen des PKGSRC, z.B.:
ftp://ftp.netbsd.org/pub/pkgsrc/release/pkgsrc-2005Q4.tar.bz2

Die Release-Version von PKGSRC nehme ich, damit sich auch ALLES sauber kompilieren lässt und ich keine nervigen Abbrüche beim kompilieren habe.

Nun habe ich ein Problem!
In der Version 2005Q4 lässt sich bei mir weder Gnome noch KDE3 in einem Rutsch durchkompilieren (ich verwende pkg_comp mit den offiziellen Sets).
Allerdings habe ich das native X11 (XFree86) gegen Xorg ausgewechselt. Scheinbar ist der PKGSRC in dieser Form nicht mehr als "stabil" zu betrachten....
Ich kann nicht sagen ob er es mit dem nativen NetBSD-X11 stabil machen würde, da ich diese Tests erst jetzt gemacht habe.


Hat einer Erfahrungen mit dem Release-PKGSRC und derartigen Problemen?
Kann einer bestätigen, das es nur mit nativem X11 stabil kompiliert (ist von mir erstmal nur eine Vermutung)?
 
Hallo!

Ich benutze die pkgsrc-RELEASES um auf nicht NetBSD-Plattformen Packete zu bauen, bei Solaris nehme ich z.B. das naitive X11, also openwin und hier gibt es ebenfalls oft unsaubere Kompilierungen.

Ich glaube nicht, dass in einem RELEASE alle Packete zu 100% sofort fehlerfrei durchrennen, aber bei so großen META-PACKAGES wie GNOME und KDE sollte es hier eigentlich funktionieren - kann mich aber auch irren!

Unter NetBSD ging es aber meist ohne größeres Zutun.

Was passiert wenn du das org. XFree86 nimmst?

Gruß Frank
 
franco98 schrieb:
Hallo!

Ich benutze die pkgsrc-RELEASES um auf nicht NetBSD-Plattformen Packete zu bauen, bei Solaris nehme ich z.B. das naitive X11, also openwin und hier gibt es ebenfalls oft unsaubere Kompilierungen.

Ich glaube nicht, dass in einem RELEASE alle Packete zu 100% sofort fehlerfrei durchrennen, aber bei so großen META-PACKAGES wie GNOME und KDE sollte es hier eigentlich funktionieren - kann mich aber auch irren!
Sowas habe ich auch vor!
Ich will ein Slackware ver-NetBSD'n mit dem PKGSRC, damit ich für beide Systeme meine PKG-Wartungsscripte verwenden kann.
Später will ich mir auch mal OpenSolaris ansehen und dort auch PKGSRC verwenden.
:D

franco98 schrieb:
Unter NetBSD ging es aber meist ohne größeres Zutun.

Was passiert wenn du das org. XFree86 nimmst?

Gruß Frank
Das habe ich noch nicht ausprobiert, aber da meine Test-/Spiele-Kiste noch nicht fertig ist, kann ich da ja mal testen was passiert wenn ich das native X11 (XFree86) verwende.
Wär aber sehr ärgerlich, wenn ich XFree86 fahren muss um meine Pakete "automatisch" übersetzen zu lassen.... :grumble:
 
franco98 schrieb:
Hallo!

Ich benutze die pkgsrc-RELEASES um auf nicht NetBSD-Plattformen Packete zu bauen, bei Solaris nehme ich z.B. das naitive X11, also openwin und hier gibt es ebenfalls oft unsaubere Kompilierungen.

Ich glaube nicht, dass in einem RELEASE alle Packete zu 100% sofort fehlerfrei durchrennen, aber bei so großen META-PACKAGES wie GNOME und KDE sollte es hier eigentlich funktionieren - kann mich aber auch irren!

Unter NetBSD ging es aber meist ohne größeres Zutun.

Was passiert wenn du das org. XFree86 nimmst?

Gruß Frank
.... ich hab auch eine ULTRA5 mit Solaris 5.9 im Keller, :D
nur leider keine Zeit um mich damit näher auseinander zu setzen .... :grumble:
 
franco98 schrieb:
Ich benutze die pkgsrc-RELEASES um auf nicht NetBSD-Plattformen Packete zu bauen, bei Solaris nehme ich z.B. das naitive X11, also openwin und hier gibt es ebenfalls oft unsaubere Kompilierungen.
Für Solaris gibt es ja inzwischen den SUN-CC für lau.
Schon geschafft/versucht mit dem SUN-CC pkgsrc zu bootstrapen?
Wie machst Du es, daß er das nativen X11 nimmt?

Sorry für die DAU Fragen und das stellen solcher neuen Fragen in diesem Thread.
 
Yoda schrieb:
Hi Leute,
ich arbeite seit einiger Zeit daran mein Scource-Aktuallisierung (src, xsrc und pkgsrc) zu automatisieren. Dazu verwende ich nur die Release-Versionen des PKGSRC, z.B.:
ftp://ftp.netbsd.org/pub/pkgsrc/release/pkgsrc-2005Q4.tar.bz2

Die Release-Version von PKGSRC nehme ich, damit sich auch ALLES sauber kompilieren lässt und ich keine nervigen Abbrüche beim kompilieren habe.

Nun habe ich ein Problem!
In der Version 2005Q4 lässt sich bei mir weder Gnome noch KDE3 in einem Rutsch durchkompilieren (ich verwende pkg_comp mit den offiziellen Sets).
Allerdings habe ich das native X11 (XFree86) gegen Xorg ausgewechselt. Scheinbar ist der PKGSRC in dieser Form nicht mehr als "stabil" zu betrachten....
Ich kann nicht sagen ob er es mit dem nativen NetBSD-X11 stabil machen würde, da ich diese Tests erst jetzt gemacht habe.


Hat einer Erfahrungen mit dem Release-PKGSRC und derartigen Problemen?
Kann einer bestätigen, das es nur mit nativem X11 stabil kompiliert (ist von mir erstmal nur eine Vermutung)?
Die Erfahrung mache ich mit pkgsrc-2005Q4 auch gerade unter Solaris auf SPARC. Habe jetzt endlich mit manueller Nacharbeit den MySQL 5 Server gebaut bekommen, um dann bei PHP5 wieder auf die Nase zu fallen. Das PHP5-Basispaket ging, es klemmt aber an einigen Erweiterungen. Es scheitert an php-mysql und einige andere Sachen wollen partout auch nicht, nur ein paar Beispiele (postgresql80-client, freetds, openldap). ;'(

Gruß c.
 
Zuletzt bearbeitet:
Was ist denn an der Release-Version von PKGSRC "RELEASE"? Wenn das auch nicht besser geht als der normale "STABLE"?
Sowas ärgert mich tierisch....

Ich denke die kompilieren einfach mal alles und wenn das endlich geht, dann wird "RELEASE" draufgestempelt... aber scheinbar machen die das etwas anders...

Weiß einer wie die Bedingungen für die RELEASE-Version genau aussehen? Was machen die in den drei eingefrohrenen Wochen immer?
 
chaos schrieb:
Schon geschafft/versucht mit dem SUN-CC pkgsrc zu bootstrapen?
Wie machst Du es, daß er das nativen X11 nimmt?

Ich habe pkgsrc mit gcc-2.95, gcc-3.3.4, gcc-3.3.5 und sunpro 11 erfolgreich übersetzt.

Die besten Ergebnisse hatte ich mit sunpro und gcc-3.3.5, es sind ja auch die neusten der vier Compiler!

Das native X11 nehme ich durch Eintragen in die /etc/mk.conf:

X11_TYPE?=native
X11BASE?=/usr/X11R6 # bzw. unter Solaris
X11BASE?=/usr/openwin

Ich benutze aber xpkgwedge unter Solaris nicht:

USE_XPKGWEDGE?=No

Für den SUN-Compiler:

PKGSRC_COMPILER?=sunpro # bzw. gcc

Evt. muß noch ein Eintrag für imake gemacht werden:

IMAKE?= ${X11BASE}/bin/imake ${IMAKEOPTS}

For Solaris with gcc:

IMAKEOPTS= -DHasGcc2=YES -DHasGcc2ForCplusplus=YES

Gruß Frank
 
So, nach einigen Tests habe ich jetzt fest gestellt, das das installierte/benutzte X11 sehr wichtig ist!!!
Ich bin jetzt wieder von Xorg auf Native (XFree86) zurück gegangen... und siehe da, es gibt wesentlich weniger Probleme beim kompilieren!!!!

Die Moral von der Geschicht:
"Ändere an der Basis so wenig wie möglich, wenn Du so wenig Probleme wie möglich willst!" :-)
 
Yoda schrieb:
... und siehe da, es gibt wesentlich weniger Probleme beim kompilieren!!!!

Was trotzdem unlogisch ist!

Wenn du ein minimales NetBSD ohne X11 installierst und dann mit pkgsrc dir ein
X11R6 deiner Wahl kompilierst, z.B. Xorg und dann erst deinen Window_Manager übersetzt, X11_TYPE?=xorg in /etc/mk.conf gesetzt hast und X11BASE?=$WoDeinX11R6Sitzt auch stimmt - warum sollten dann die Sources meckern?:confused:

Die Patches, z.B. die für KDE sind meiner Meinung nach nicht für eine bestimmte X11-Version geschrieben und den Sources sollte es Wurscht sein!

Gruß Frank
 
franco98 schrieb:
Was trotzdem unlogisch ist!

Wenn du ein minimales NetBSD ohne X11 installierst und dann mit pkgsrc dir ein
X11R6 deiner Wahl kompilierst, z.B. Xorg und dann erst deinen Window_Manager übersetzt, X11_TYPE?=xorg in /etc/mk.conf gesetzt hast und X11BASE?=$WoDeinX11R6Sitzt auch stimmt - warum sollten dann die Sources meckern?:confused:

Die Patches, z.B. die für KDE sind meiner Meinung nach nicht für eine bestimmte X11-Version geschrieben und den Sources sollte es Wurscht sein!

Gruß Frank
Keine Ahnung, wenn ich das wüsste hätte ich es behoben! Für mich ist das auch unlogisch, aber was soll ich machen....

Auf jeden Fall kamen immer irgendwelche Fehler, als ich dann in der Sandkiste (pkg_comp) die PKGs mit nativem X11 kompiliert hatte ging alles.
Dann habe ich alle PKGs deinstalliert , die X-Sets installiert und die vorbereiteten PKGs aus der Sandkiste installiert.
Natürlich lassen sich immernoch nicht alle gewünschten PKGs in einem Rutsch übersetzen, aber immerhin schon fünf mal soviel und damit fast alle....
 
franco98 schrieb:
Was trotzdem unlogisch ist!

Wenn du ein minimales NetBSD ohne X11 installierst und dann mit pkgsrc dir ein
X11R6 deiner Wahl kompilierst, z.B. Xorg und dann erst deinen Window_Manager übersetzt, X11_TYPE?=xorg in /etc/mk.conf gesetzt hast und X11BASE?=$WoDeinX11R6Sitzt auch stimmt - warum sollten dann die Sources meckern?:confused:

Die Patches, z.B. die für KDE sind meiner Meinung nach nicht für eine bestimmte X11-Version geschrieben und den Sources sollte es Wurscht sein!

Gruß Frank
...vielleicht habe ich ja auch ein paar Variablen zu wenig in der /etc/mk.conf eingetragen (hatte nur die X11_TYPE definiert)... jedenfalls klappt es jetzt besser... :D
 
Yoda schrieb:
...vielleicht habe ich ja auch ein paar Variablen zu wenig in der /etc/mk.conf eingetragen (hatte nur die X11_TYPE definiert)... jedenfalls klappt es jetzt besser... :D

Ich habe selber pkg_comp noch nicht benutzt, aber bei mk/sandbox muß ich auch noch explizit mitgeben, was für ein X ich habe, sprich --xsrc=/usr/xsrc. Hast Du mal geschaut, ob es was analoges für pkg_comp gibt ?
 
@Threadstarter

Bin ich erblindet oder wo ist hier die konkrete Fehlermeldung? ^^

Xorg sollte meist keine Probleme bereiten, allerdings gab es vor einigen Wochen Probleme bei der Speicherverwaltung, die zB bei QT/KDE-builds mit dem Linker auftraten und in NetBSD 3 lange Zeit nicht behoben wurden.
 
CAMISOLITE schrieb:
Ich habe selber pkg_comp noch nicht benutzt, aber bei mk/sandbox muß ich auch noch explizit mitgeben, was für ein X ich habe, sprich --xsrc=/usr/xsrc. Hast Du mal geschaut, ob es was analoges für pkg_comp gibt ?
Ja, da gibt es auch sowas. Was muss denn als X-Quelle angegeben werden, wenn man Xorg aus dem PKGSRC verwendet?
 
Tohuwabohu! schrieb:
@Threadstarter

Bin ich erblindet oder wo ist hier die konkrete Fehlermeldung? ^^

Xorg sollte meist keine Probleme bereiten, allerdings gab es vor einigen Wochen Probleme bei der Speicherverwaltung, die zB bei QT/KDE-builds mit dem Linker auftraten und in NetBSD 3 lange Zeit nicht behoben wurden.
Nein, Du bist nicht plötzlich erblindet!
Ich habe keine Fehlermeldung gepostet, da es bei verschiedenen Ports unterschiedliche waren und nach einem "cvs update" dann wieder andere und auch bei anderen Ports.

Die am häufigsten aufgetretene lautete so ungefähr, das er das Wort ")" nicht finden konnte (bei über 50 Ports). Hab dazu gegoogelt und fand auch andere mit diesem Problem, nur keiner hatte eine Lösung. Dann hab ich wieder umgeschwenkt auf das native XFree86 und dann liessen sich die meisten dieser Ports kompilieren....
 
Yoda schrieb:
Ja, da gibt es auch sowas. Was muss denn als X-Quelle angegeben werden, wenn man Xorg aus dem PKGSRC verwendet?

Da ich Xorg unter NetBSD noch nicht benutzt habe weiß ich das nicht wirklich. Guck' doch mal unter /usr/pkg/ oder wo immer Du Deine Pakete hininstallierst. Eventuell nutzt pkgsrc hier ja auch /usr/X11R6... - glaube ich aber nicht. Ansonsten bliebe nur noch der unpraktische Ort /usr/pkgsrc/X11/...
 
Xorg liegt normalerweise in /usr/pkg/xorg, ich hab allerdings auch einen Link von /usr/X11 und /usr/X11R6 drauf gemacht.
 
zmieff schrieb:
Xorg liegt normalerweise in /usr/pkg/xorg, ich hab allerdings auch einen Link von /usr/X11 und /usr/X11R6 drauf gemacht.
Aber den Pfad übergibt man doch nicht an "pkg_comp" an stelle von "--xsrc=/usr/xsrc"! Der will den Pfad zu den Sourcen haben!
 
CAMISOLITE schrieb:
Da ich Xorg unter NetBSD noch nicht benutzt habe weiß ich das nicht wirklich. Guck' doch mal unter /usr/pkg/ oder wo immer Du Deine Pakete hininstallierst.
Ich glaube nicht, das der Pfad geht, denn man muss doch den Pfad zu den Soucen angeben.

CAMISOLITE schrieb:
Eventuell nutzt pkgsrc hier ja auch /usr/X11R6... - glaube ich aber nicht. Ansonsten bliebe nur noch der unpraktische Ort /usr/pkgsrc/X11/...
Das habe ich noch nicht ausprobiert. Aber muss dann nicht der Metaport angegeben werden?
 
Yoda schrieb:
Aber den Pfad übergibt man doch nicht an "pkg_comp" an stelle von "--xsrc=/usr/xsrc"! Der will den Pfad zu den Sourcen haben!


/usr/xsrc sind die Sourcen !!! (für XFree86)

Und für Xorg habe ich gerade mal nachgesehen. Es gibt ein Paket pkgsrc/x11/xorg-libs, da sind die Header-Files drin, die andere Pakete möglicherweise mitnutzen wollen. Also wird es wie von zmieff beschrieben irgendwo unter /usr/pkg/xorg aufzufinden sein. Guck' halt mal nach, es sollte ein Pfad ähnlich /usr/pkg/xorg/...blablubb.../lib/src/...trallala... sein.
 
CAMISOLITE schrieb:
.... Es gibt ein Paket pkgsrc/x11/xorg-libs, da sind die Header-Files drin, ....

Achso, er braucht nur den Pfad zu den Header-Dateien? Das reicht?
Muss ich dann bei Gelegenheit mal testen.
Leider habe ich jetzt alles wieder auf XFree86 umgestellt.... sodas ich erst nächste Woche dazu kommen werden dieses mal zu testen.

Wär ja cool, wenn man sich so auch seine Sets mit Xorg kompilieren könnte. :D
 
PKGSRC-Release wird unzureichend getestet

Ich habe jetzt noch ein paar Tests gemacht.

Die angehängte Liste von PKG-Pfaden (in FreeBSD heißen die "origin"), habe ich in meiner "Wunschkonfiguration" (Xorg und german) durchgeführt, es wurden etwas über 150 PKGs gebaut. Dann habe ich auf natives X11 (XFree86) zurück gestellt und ich konnte schon 228 PKGs bauen. Dann habe ich aus der mk.conf die deutsche Spracheinstellung wider entfernt (#PKG_LANG=german) und siehe da, er hat jetzt schon 239 PKGs gebaut und ist immernoch dabei!!!

Um für jeden PKG-build eine klar definierte Umgebung zu schaffen, habe ich die Liste mit dieser Kommandozeile abarbeiten lassen:

cat /home/etc/pkgchk.conf_buildliste | while read PAKB;do pkg_comp -C /home/etc/pkg_comp.conf auto $PAKB ; done

Zu den Tests wurden nur die Einträge "X11_TYPE" und "PKG_LANG" in der Datei /etc/mk.conf entsprechend angepasst. Die Dateien
- /home/etc/pkgchk.conf_buildliste
- /home/etc/pkg_comp.conf
sowie die PKGSRC-Version und sämtliche OS-Einstellungen (Version und Konfiguration) wurden seit Begin des Tests bis jetzt nicht verändert. Natürlich wurde nachdem aller ersten Test mit Xorg, Xorg deinstalliert und dann die X-Sets installiert, sonst wurde an den installierten PKGs nichts geändert. Auch wurden alle Tests auf meinem einzigen Laptop durchgeführt.

Soweit meine bisherigen Ergebnisse. Wie es aussieht, wird die PKGSRC-Release-Version nur in englischer Sprache und in Default-Konfiguration getestet.

Vor diesem Hintergrund, sollte ich erst alle Meine PKGs mit der Einstellung "PKG_LANG=german" bauen, und alle die sich so nicht bauen liessen, anschliessend ohne die Angabe der "PKG_LANG"-Variable nocheinmal bauen lassen. Dann habe ich die PKGs wenigstens in englisch. Eines dieser PKGs ist der "netscape7", den kann man praktisch nie in deutsch bauen, da im Makefile immer die neueste Version gevordert wird und diese aber praktisch nie in deutsch existiert... davon aber abgesehen kann man den "netscape7" auch nicht automatisch bauen lassen, da er interaktive eingaben als root erwartet. Das aber nur am Rande.
 

Anhänge

  • pkgchk.conf_buildliste.txt
    3,7 KB · Aufrufe: 285
Test: Bilanz

Also, ich hatte mich ja Eingangs darüber beschwert, daß unser lieber PKGSRC in der Release-Version sich nicht ordentlich kompilieren lässt.
Jetzt habe ich da ein paar Tests gemacht, die Ergebnisse sehen wie folgt aus:

Ich habe meine Liste abarbeiten lassen und die PKGs wurden mit pkg_comp und der Option auto für jedes einzelne PKG mit einem NetBSD 3.0 kompiliert.

Es wurden
- 228 PKGs mit PKG_LANG=german in der "/etc/mk.conf" kompiliert;
- 399 PKGs ohne PKG_LANG-Variable in der "/etc/mk.conf" kompiliert;
Im Letzten Fall wurden aber trotzdem noch 60 PKGs aus der Liste nicht gebaut! Warum die nicht gingen, werde ich bei Gelegenheit nachprüfen.

Als Referenz habe ich meine eigene PKG-Auswahl verwendet, die ich unten als Datei angehängt habe.
 
Zurück
Oben