Der große pkg (ehemals pkgng) Thread

Nein, nicht mit dem Hammer raufhauen! Das löst keine Probleme für niemanden, am wenigsten für dich. Was ist, wenn es in 14 Tagen wieder so knallt? Dann wieder alles neu bauen? Lass es uns lieber etwas konstruktiver angehen. Der Fehler kommt aus "libucl", was Teil von pkg ist. Anscheinend wird diese Blibliothek genutzt, um Konfigurationsdateien zu parsen. Ein schnelles durchscrollen durch den Code zeigt, dass es mindestens deine Nutzerconfig, Paket-Manifeste und Repo-Fingerprints betrifft. Ich würde also als nächsten logischen erstmal die komplette Konfiguration /usr/local/etc aus dem Weg räumen und schauen, ob das hilft.
 
Es gibt auch noch den Tipp ein
Code: 
 rm -f /var/db/pkg/repo-*
zu machen und anschließend das Remote-Repo per
Code: 
pkg update
neu zu synchronisieren. Das aber alles natürlich nur, wenn überhaupt Pakete aus entfernten Quellen genutzt werden.
 
´Z.B. löst diese pkg/repos/FreeBSD.conf ähnliche Fehlermeldungen aus:
Code: 
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest,
  mirror_type: "srv",
  enabled: yes
}
(Der Fehler sind fehlende Anführungszeichen in der zweiten Zeile)
 
Du hast Recht Yamagi, es liegt an irgendeiner Einstellung in /usr/local/etc. Habe "etc" nur umbenannt. Kann ich den Ordner bedenkenlos löschen?

Edit: habe mal alles, was nicht pkg betrifft, aus meinem "etc2"-Ordner nach "etc" kopiert. Bis jetzt hält es. Man muss wohl doch nicht mit dem Hammer raufhauen.
 
Dann mal die pkg Dateien eine nach der anderen wieder rein, bis du die Schuldige hast. Die dann Zeile für Zeile durchgehen oder hier posten. Der Fehler wird sich schon finden lassen.
 
Die schuldige Datei ist /usr/local/etc/pkg/repos/wine.conf:
Code: 
 wine:
  URL: http://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/dbn/repos/wine/${ABI}/latest
  ENABLED: yes
  MIRROR_TYPE: HTTP
  PUBKEY: /usr/local/etc/pkg/repos/wine.cert

Bezogen auf den Fehler "error on line 5 at column 44: 'unfinished value', character: '" muss es der Eintrag PUBKEY sein.
 
Bei mir tritt es nicht auf. Also definitiv ein Bug oder ich mache noch was anders als du:
Code: 
root@lennart:pts/6 ...pkg/repos> pkg audit -F
pkg: /usr/local/etc/pkg/repos//wine.conf file is using a deprecated format. Please replace it with the following:
====== BEGIN /usr/local/etc/pkg/repos//wine.conf ======
"wine": {
    "URL": "http://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/dbn/repos/wine/${ABI}/latest",
    "ENABLED": true,
    "MIRROR_TYPE": "HTTP",
    "PUBKEY": "/usr/local/etc/pkg/repos/wine.cert"
}

====== END /usr/local/etc/pkg/repos//wine.conf ======
Allerdings könntest du mal probieren, was er vorschlägt. wine.conf neu anlegen:
Code: 
"wine": {
    "URL": "http://ftp.freebsd.org/pub/FreeBSD/ports/local-distfiles/dbn/repos/wine/${ABI}/latest",
    "ENABLED": true,
    "MIRROR_TYPE": "HTTP",
    "PUBKEY": "/usr/local/etc/pkg/repos/wine.cert"
}
 
Weil der Zugriff auf den SRV record von pkg.freebsd.org hinter so manchem Firmenproxy (wie bei uns) nicht möglich war, wurde endlich ein normaler A record angelegt. Der sollte aber nur als Notlösung benutzt werden, weil hier immer auf den selben Server gegangen wird. Beim SRV record wird der Server mit der geringsten Latenz ausgewählt.
 
Ich hab mal wieder ein Problem mit den Konflikten zwischen devel/py-distribute und devel/py-setuptools.

/usr/ports/updating sagt mit Datum 2013-03-05:
Code: 
Affects: users of devel/py-setuptools (i.e you)
Affects: users of devel/py-setuptools (i.e you)
Author: rm@FreeBSD.org
Reason: 
devel/py-setuptools was replaced with devel/py-distribute. Please do the following according to package manager used. py-setuptools port will be removed shortly. 

# portmaster -o devel/py-distribute devel/py-setuptools or 
# portupgrade -fo devel/py-distribute devel/py-setuptools or 
# pkg set -o devel/py-setuptools:devel/py-distribute 
# pkg install -f devel/py-distribute
Gesagt-getan:
Code: 
$ sudo pkg set -o devel/py-setuptools:devel/py-distribute
Password:
Change origin from devel/py-setuptools to devel/py-distribute for all dependencies? [y/N]: y

Aber die Wirkung bleibt aus:
Code: 
$ sudo pkg -U upgrade
[...]
Proceed with upgrading packages [y/N]: y
Checking integrity...pkg: WARNING: locally installed py27-distribute-0.6.35 conflicts on /usr/local/bin/easy_install with:
  - py27-setuptools-1.1.7_1
pkg: WARNING: locally installed py27-distribute-0.6.35 conflicts on /usr/local/bin/easy_install-2.7 with:
  - py27-setuptools-1.1.7_1
pkg: WARNING: locally installed py27-distribute-0.6.35 conflicts on /usr/local/lib/python2.7/site-packages/easy-install.pth.dist with:
  - py27-setuptools-1.1.7_1

Gibt es irgendeine Lösung für dieses Problem?
 
Der Hammer hilft:
Code: 
pkg remove -f py27-distribute-0.6.35
Gleich danach dann die nächste Runde "pkg upgrade".
 
Super - hat so funktioniert! Vielen Dank!

Allerdings bin ich überrascht über das Ergebnis: Jetzt sind die py-setuptools doch installiert. Ich hatte erwartet, dass die durch mein vorheriges
Code: 
pkg set -o devel/py-setuptools:devel/py-distribute
durch py-distribute ersetzt würden. Wie kommt's?
 
Bei mir sagt /usr/ports/UPDATING zu den py-setuptools:
20131127:
AFFECTS: users of devel/py-distribute (i.e you)
AUTHOR: wg@FreeBSD.org

devel/py-distribute was replaced with devel/py-setuptools. Please do
the following according to package manager used. py-distribute port
will be removed shortly.

# portmaster -o devel/py-setuptools devel/py-distribute
or
# portupgrade -fo devel/py-setuptools devel/py-distribute
or
# pkg set -o devel/py-distribute:devel/py-setuptools
# pkg install -f devel/py-setuptools
Zum Vergrößern anklicken....
Das ist auch mit Freshports stimmig:
http://www.freshports.org/devel/py-distribute/
http://www.freshports.org/devel/py-setuptools/
 
Danke Fusselbär. Ich hatte das Pech, auf freshports.org zuerst nach py-setuptools zu schauen und fand dort den älteren Hinweis, dass py-setuptools entfernt werden soll und man py-distribute verwenden solle. Ein kurzer Blick auf http://www.freshports.org/devel/py-distribute/ schien das auch zu bestätigen, denn als erstes sieht man dort die veraltete Package-Description "Distribute is intended to replace Setuptools as the standard method for working with Python module distributions."

Also nun doch alles umgekehrt: devel/py-distribute ist (fast) tot. Es lebe devel/py-setuptools.

PS: Mir tun die Portmaintainer leid!
 
Ich habe FreeBSD 10 RC2 x86 in einer virtuellen Box installiert um zu sehen ob ich es schon produktiv einsetzen kann. Leider kann ich pkg nicht installieren:
Code: 
>pkg
... lzma library error: corrupted input data
Das selbe Problem tritt auch auf, wenn ich Ports installieren moechte, da immer versucht wird pkg als erste Abhaengigkeit zu installieren.

Als Pkg-Site habe ich sowohl pkg.FreeBSD als auch pkg-test.FreeBSD versucht.
 
vimix schrieb:
Ich habe FreeBSD 10 RC2 x86 in einer virtuellen Box installiert um zu sehen ob ich es schon produktiv einsetzen kann. Leider kann ich pkg nicht installieren:
Code: 
>pkg
... lzma library error: corrupted input data
Das selbe Problem tritt auch auf, wenn ich Ports installieren moechte, da immer versucht wird pkg als erste Abhaengigkeit zu installieren.

Als Pkg-Site habe ich sowohl pkg.FreeBSD als auch pkg-test.FreeBSD versucht.
Zum Vergrößern anklicken....
Kann ich nicht bestätigen. Ich habe FreeBSD 10.0-RC2/amd64 auf einem Notebook laufen und habe mich nicht darum gekümmert ob ich pkg nutzen möchte oder nicht. Ich verwende auf dem Notebook ebenfalls erfolgreich ports. Ein whereis pkg wirft mir: pkg:/usr/sbin/pkg aus. Das heißt für mich, dass pkg bereits im Basissystem enthalten ist und nicht nachinstaliert wird/werden musste.

Hast du deine Maschine evtl. von 9.x auf 10.0-RC2 aktualisiert?

Gruß
 
In kurz: ports = die Programme werden als Sourcecode runtergeladen und auf deinem Rechner kompiliert /// pkg = ports die irgendwo anders kompiliert wurden und du installierst das fertige Paket.

Das Beste aus beiden Welten bekommst du dann z.B. mit poudriere. Dort werden die Ports auf deinem Rechner nach deinen Wünschen kompiliert und als pkg bereitgestellt.

So erspart man sich u.a. die Abhängigkeiten die man nur zum Bauen der Pakete braucht, installiert zu haben.
 
Danke.

Allerdings habe ich noch paar Fragen.

Die fertig kompilierten programme sind in meinem Repository, oder?

Beim Kompilieren schreibt man sich sozusagen ein programm nach seinen Wuenschen um, oder?
 
Bevor ich mich jetzt in die tiefen des Internet's stürze, wollte ich fragen, ob jemand eine Anleitung kennt, mit der man eigene Tools als Pakete in PKGNG erstellen kann. Ich habe hier ein paar "Nagios- Skripts" welche ich gerne als PKG Paket auf meine Server verteilen möchte. Oder jemand eine Idee, wie man das einfach lösen könnte?

Danke :)
 
Die erste Alpha von pkg 1.3 ist heute Abend erschienen. Die interessanteste Aenderung betrifft wohl den Abhaengigkeitsloeser, der nun als vollwertigen SAT Solver implementiert ist. Damit sollten einige Probleme, die wir auch hier hatten beim pkg upgrade hoffentlich der Vergangenheit angehoeren. Eine wichtige Aenderung fuer User aelterer Versionen ist wohl das PACKAGESITE nun komplett entfernt wurde. Damit muss man nun zwingend das neue repo Format benutzen.

Die vollstaendige Mail mit den wichtigsten Aenderungen ist hier:
Hello,

I'm really pleased to announce that the release process for the new major
version of pkg(8) has started with this first alpha1 release.

The main feature for this release is the complete rework of the solver.
pkg(8) now features a real SAT solver and uses it for every operations requ=
ested
by the user that may add, upgrade or remove packages.

This work is is the result of the very succesfull Google Summer of Code 201=
3, by
Vsevolod Stakhov (vsevolod@ also known as cebka). This is a major improveme=
nt
for the project, and the fundation for lots of new features in the future.

I would like to thanks Vsevolod for all the new ideas and hard work he has =
done
(not limited to the new solver.)

Back to the release now. pkg 1.3.0 comes with the following new features:
- New solver that can support external solvers using the CUDF format and the
internal SAT solver
- pkg-ssh(8) is now sandboxed using capsicum if available
- pkg-ssh(8) now uses poll(2)
- Remove StringList usage to improve portability
- Rework the build system to using autotools to help portability
- Now fetching is done to a temporary location and cleaned up if it fails
- Remove support for PACKAGESITE
- pkg-audit(8): remove support for portaudit compact database (only VulnXML=
will
be used)
- Improved UI experience based on jmmv write up
(http://julipedia.meroh.net/search/label/cli-design)
- Hide the average speed from the progress bar (confusing for users)
- Reworking the database locking mechanism into a finer grain and more clev=
er
system
- Dynamic conflict handling if a conflict on files is detected at the sanity
check level, try to solve the problem again with the new conflict informa=
tion
- Fix %t (timestamp) modifier in pkg_printf(3)
- pkg-info(8): full output now has a new field "date installed"
- New pkg -o A=3DB to overwrite configuration from command line without the=
need
of defining environment variables
- pkg-install(8): can handle local files
- pkg-add(8) is now an alias on pkg-install
- Simplify API by using more and more libucl objects (hidden behind an opaq=
ue
'pkg_object')

Thanks to everyone that has contributed code for this release:
Alberto Villa, Alexandre Perrin, Baptiste Daroussin, Brad Davis, Bryan Drew=
ery,
Jamie Landeg Jones, John Marino, Matthew Seaman, Maximilian Ga=DF, Michael
Gehring, Michael Gmelin, Rodrigo Osorio, Rui Paulo, Sean Channel, Stanislav=
E.
Putrya, Vsevolod Stakhov, Xin Li, coctic

Thanks also to all people reporting bugs, sharing ideas, testing and using
pkg(8).

regards,
Bapt
Zum Vergrößern anklicken....
 
lme schrieb:
Guck mal hier:

http://blog.des.no/2013/08/creating-pkgng-packages-without-ports/

Ansonsten in der Manpage von pkg-create
Zum Vergrößern anklicken....

Danke für den Link aber das ist nicht genau das, was ich meinte. Ich habe mir jetzt ein eigenes "Makefile" nach [1] erstellt und dieses nach "...ports/sysutils/" kopiert. in "poudriere" eingebunden und er baut mir mein Paket jetzt jede Nacht neu, wenn es eine neue Version gibt :)

[1] http://www.freebsd.org/doc/en/books/porters-handbook/book.html#porting-makefile
 
Kamikaze schrieb:
Nein, die Pakete werden ja auch aus den Ports gebaut. Das heißt du bist auf die Optionen vom Betreiber Deines Paketservers angewiesen. Hier fehlt es ein wenig an einem Management für Plugins und Flavours in der Infrastruktur.

Ich denke das wird irgendwann noch kommen aber nicht so auf die Schnelle. Dazu müssen pkgng, die Ports und pointyhat/Tinderbox weiter entwickelt werden. Das sind 3 verschiedene Baustellen. Wenn man so etwas übers Knie bricht ist am Schluss Niemand mit dem Ergebnis zufrieden.
Zum Vergrößern anklicken....

Gibt es dazu schon eine Lösung? Ich möchte im Großen und Ganzen die Pakete benutzen und einige aufgrund anderer Option "zu Fuß" erstellen. Kann ich mittels pkg lock verhindern, das die beim upgrade überbügelt werden?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben