Qualität der Pakete in pkgsrc

darktrym

darktrym

Fahnenträger
... ist nicht mehr mal befriedigt. Ich benutze zZ sowohl den NetBSD i386 als auch den AMD64 Port.
Bei beiden Varianten sind diverse Programme nicht übersetzbar, bzw. stürzen ab oder haben allgemein Fehler, vorallem AMD64. Beispiele gefällig:

1. seamonkey 1.1.7 fehlt das Schreibattribut für die Lesezeichendatei, bewirkt das Nichtspeichern der Lesezeichen, Abhilfe schafft das Attribut zu setzen.

2. fxtv stürzt beim Start ab(AMD64), xawtv lässt sich nicht mal übersetzen. Fazit: Unter AMD64 kann ich nicht fernsehen.

3. licq 1.3.5 meldet Fehler mit der Spracheinstellung deutsch(irgendwas von utf8->"" funktioniert nicht) und stürzt beim beenden auch ab. Betroffen sind i386 und AMD64 Port.

4. kaffe, xawtv lässt sich nicht übersetzen auf AMD64 obwohl die Jungs von OpenBSD das offentsichtlich hinbekommen haben. :confused:

Und das beste zum Schluss:zitter::

Im AMD64 Port kennen vi(von der CD) noch yudit,qvwm Umlaute.LANG, LC_ALL, LC_MESSAGES sind korrekt gesetzt:
Code: 
export LANG="de_DE"
export LC_MESSAGES="de_DE.ISO8859-15"
export LC_ALL="de_DE.ISO8859-15"


Die Liste ist natürlich nicht vollständig, könnte man aber beliebig fortsetzen.

:grumble: :mad:

Ich hoffe, dass das nur temporäre Probleme sind und bald gefixt werden.
 
es ist ja bekannt das es probleme gibt, auch gerade mit recht vielen ports, auch wenn ich persoenlich sagen muss, das ich nur mit den wip paketen probleme hatte, allerdings setze ich netbsd nur auf server systemen ein.
was ich allerdings nicht verstehe, warum postest du das hier, es gibt mailinglisten, wo das besser aufgehoben ist und auch nen freenode chan (#pkgsrc), wo man die maintainer zum teil antrifft.

gruss jens
 
Ich wollte nur meinen Unmut äußern, das scheinbar das Testen von neuen Versionen von Programmen zu lachs gehandhabt wird. Die Fehler waren ja nicht schwer zu finden oder schwierig zu reproduzieren. Vielleicht sollte man bei pkgsrc weniger in der Breite gehen als in die Tiefe(= bestehende Programme sollten nicht nur für die pop. Ports funktionieren) gehen.

Manchmal habe ich das Gefühl das man sich ständig mit Linux messen will, auf Kosten der Qualität.
 
darktrym schrieb:
Im AMD64 Port kennen vi(von der CD) noch yudit,qvwm Umlaute.LANG, LC_ALL, LC_MESSAGES sind korrekt gesetzt:
Code: 
export LANG="de_DE"
export LC_MESSAGES="de_DE.ISO8859-15"
export LC_ALL="de_DE.ISO8859-15"
Zum Vergrößern anklicken....

Naja, "korrekt" ist sicherlich was anderes: LANG ist falsch, LC_ALL setzt man nur, wenn man weiss, was man tut und LC_MESSAGES wird sowieso von LANG subsumiert.

Dann kann das mit dem Umlauten auch noch an der Tastatur sowie an der Shell und dem Terminal liegen.

Nicht, dass dir das jetzt weiterhelfen wuerde ... :(
 
darktrym schrieb:
[...]
1. seamonkey 1.1.7 fehlt das Schreibattribut für die Lesezeichendatei, bewirkt das Nichtspeichern der Lesezeichen, Abhilfe schafft das Attribut zu setzen.
[...]
3. licq 1.3.5 meldet Fehler mit der Spracheinstellung deutsch(irgendwas von utf8->"" funktioniert nicht) und stürzt beim beenden auch ab. Betroffen sind i386 und AMD64 Port.
[...]
Zum Vergrößern anklicken....

Wenn man Fehler und nötige Korrekturen so genau beschreiben kann, dann das bitte auch an die Mainlingliste schicken!

benutzt Du pkgsrc stable oder current?

Wg. der Umlaute: Was ergibt "cat /etc/wscons.conf |grep -i encoding" ?
 
Zuletzt bearbeitet:
Dieses Pakete habe ich als Binärpaket vom NetBSD FTP Server gezogen.
Und in der wscons steht natürlich
encoding=de.nodead
Zum Vergrößern anklicken....
.

Die Fehler bei den Umlauten treten nicht in xterm(Befehlseingabe) oder in der Shell (Befehlseingabe) auf. Nur sobald ich die betroffenen Programme(vi, yudit) starte(von xterm oder Shell) gibts die beschriebenen Probleme. Die Umlaute sehen in etwa so aus
\xfe
Zum Vergrößern anklicken....
statt ü.

Terminaltyp wsvt25 in der ttys eingetragen und 80x50 in der wscons.conf. Wie schon gesagt, die selbe Einstellung im i386 Port funktioniert natürlich.:confused:
 
darktrym schrieb:
... ist nicht mehr mal befriedigt. Ich benutze zZ sowohl den NetBSD i386 als auch den AMD64 Port.
Bei beiden Varianten sind diverse Programme nicht übersetzbar, bzw. stürzen ab oder haben allgemein Fehler, vorallem AMD64. Beispiele gefällig:

....

:grumble: :mad:

Ich hoffe, dass das nur temporäre Probleme sind und bald gefixt werden.
Zum Vergrößern anklicken....

Ja! Das ist auch der Grund gewesen warum ich wieder zu FreeBSD zurückgegangen bin.
Ich habe die Erfahrung gemacht das es kein temporäres Problem ist.

Nachdem ich über 6 Monate alle Varianten des PKG bauens ausprobiert hatte und auch die ChRoot dabei modifiziert hatte und mit unterschiedlichen Reihenfolgen gearbeitet hatte,
hatte ich kleine Erfolge erziehlt...
aber der eigentliche Grund, wie sich herrausstellte, liegt an der Sprache!!!

Paradebeispiel ist der Netscape, denn der hatte das Problem eigentlich IMMER.
Stellt man das System auf Deutsch, dann will er mit Gewalt die neueste Version in deutsch haben. Das gibt es aber niemals!!! Die deutsche Version ist immer veraltet und wird mit einem aktuellen pkgsrc NIE installiert werden können!

Wenn man das System in den Standardeinstellungen läßt, kann man fast alle Pakete kompilieren aber wehe dem, der sein System etwas anpassen will.... :grumble:

Jetzt will ich es mit NetBSD 4.0 auf meiner Testmaschine nochmal versuchen.
Das könnte möglicherweise auch Dein Problem lösen, wenn es so geht wie ich es mir vorstelle/wünsche.

Dafür habe ich einen eigenen Post aufgemacht:
http://www.bsdforen.de/showthread.php?p=177080
 
die Möglichkeiten sind verschieden, einmal kann man das über die login.conf mitgeben, über die make.conf und über die locale,naja das das export Lang=wie oben beschrieben eben
 
Flex6 schrieb:
die Möglichkeiten sind verschieden, einmal kann man das über die login.conf mitgeben, über die make.conf und über die locale,naja das das export Lang=wie oben beschrieben eben
Zum Vergrößern anklicken....

login.conf/locale/LANG=".." können ja eigentlich nicht das Problem sein. Und bezüglich make.conf bzw. mk.conf: PKG_LANG?="..." wird laut Doku nur von netscape7 und openoffice verwendet. Vielleicht ist das nicht mehr aktuell? Aber wenn "nur ca. 60% der gewünschten Pakete kompilieren" also immerhin ca. 40% nicht (!), dann muss da wohl ein anderes Problem vorliegen.
 
mawei schrieb:
login.conf/locale/LANG=".." können ja eigentlich nicht das Problem sein. Und bezüglich make.conf bzw. mk.conf: PKG_LANG?="..." wird laut Doku nur von netscape7 und openoffice verwendet. Vielleicht ist das nicht mehr aktuell? Aber wenn "nur ca. 60% der gewünschten Pakete kompilieren" also immerhin ca. 40% nicht (!), dann muss da wohl ein anderes Problem vorliegen.
Zum Vergrößern anklicken....

Das ist schon eine Weile her (zu Zeiten von NetBSD 3.0), da hab ich nix schriftliches mehr (seit dem läuft ja FreeBSD bei mir wieder) aber ich hab das Userland über locale und die kompilierumgebung per make.conf getunet.
Ich hatte da natürlich etwas mehr als nur die Sprache wunschgemäß umgestellt aber alles strickt nach Docu. Nur auf 100% bin ich auch mit einem plain-System nie gekommen, nur die Sprachanpassung war am gravierensten.

Damals hab ich mir SETs frisch aus den aktuellsten RELEASE-src gebaut und dann mit diesen SETs die Sandkiste um die PKGs zu bauen. Die korrekt gebauten PKGs hab ich dann auf all meinen Systemen (Server, Desctop und Laptop) reingepfiffen. Nur waren das nicht soviele wie ich wollte....
 
Yoda schrieb:
Ich hatte da natürlich etwas mehr als nur die Sprache wunschgemäß umgestellt aber alles strickt nach Docu. Nur auf 100% bin ich auch mit einem plain-System nie gekommen, nur die Sprachanpassung war am gravierensten.
Zum Vergrößern anklicken....

Wer kommt schon auf 100% - schaffen ja nicht mal die pkgsrc-Entwickler ;-)

Dachte ich mir aber schon, dass es nicht allein an den Spracheinstellungen gelegen haben kann.
 
Welche Version von "pkgsrc" verwendet Ihr?
Ich hab bis jetzt immer die Quatalsversion verwendet (Release), weil ich dachte da ist die Wahrscheinlichkeit möglichst viele PKGs kompilieren zu können, größer.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben