Wie macht man ein Update/Upgrade von installierten Pkg's in NetBSD (suber)???

Was cpu frequency scaling angeht - für PowerNow! gibts nen patch von Martin Végiard. Den verwende ich selber. Ist allerdings z.Z. noch fraglich obs der in 3.0 schafft. Was Speedstep betrifft sollte "options ENHANCED_SPEEDSTEP" Abhilfe schaffen. Aber nagel mich bitte nicht drauf fest. Achja: sysutils/estd
 
tenco schrieb:
Was cpu frequency scaling angeht - für PowerNow! gibts nen patch von Martin Végiard. Den verwende ich selber. Ist allerdings z.Z. noch fraglich obs der in 3.0 schafft. Was Speedstep betrifft sollte "options ENHANCED_SPEEDSTEP" Abhilfe schaffen. Aber nagel mich bitte nicht drauf fest. Achja: sysutils/estd
Zum Vergrößern anklicken....

Cooler Tipp!
Werde ich werde das mal ausprobieren. In der Kerneldatei steht "Enhanced SpeedStep Technology in the Pentium M", ich hab in meinem Laptop aber einen "Athlon XP 2000+" (glaub ich), geht das denn trotzdem? Ich probier es auf jeden Fall mal aus! :)
 
quarzsnoopy schrieb:
In der Kerneldatei steht "Enhanced SpeedStep Technology in the Pentium M"
Zum Vergrößern anklicken....

SpeedStep ist Intel only.

ich hab in meinem Laptop aber einen "Athlon XP 2000+" (glaub ich), geht das denn trotzdem?
Zum Vergrößern anklicken....

Für den Athlon brauchst du den Powernow Patch. Leider habe ich hier nur einen für -current (~3.0BETA) und nicht für 2.0.2. Martin Végiard ist aber öfter im IRC-Channel #netbsd und/oder #netbsd-devel auf irc.freenode.net anzutreffen (nick wahrscheinlich "deadbug"). Setz dich doch mit ihm in Verbindung, er wird dir vielleicht auch bei der Installation helfen (er such dringend Versuchskaninchen... ;) ). Seine E-Mail Addy hätte ich glaub ich auch noch hier.
 
tenco schrieb:
...Leider habe ich hier nur einen für -current (~3.0BETA) und nicht für 2.0.2....
Zum Vergrößern anklicken....

mmh, welche CVS-tag's muss ich denn für die "3.0_BETA" angeben? Ich habe es mal mit "netbsd-3" versucht, hab aber keine Ahnung was ich mir da gezogen hab...
was bedeuten die folgenden tag's:

"netbsd-3" => ?
"netbsd-2" => ?
"netbsd-2-0" => ?

netbsd-2-0-2 hab ich mir bis jetzt immer gesaugt, wenn ich es brauchte. Das kenne ich auch, das ist "NetBSD 2.0.2 RELEASE + Sicherheitspatches", aber was sind die anderen?
Ist "netbsd-2" oder "netbsd-2-0" die "STABLE"???

Auf der NetBSD-Seite (http://www.netbsd.org/Releases/release-map.html) hab ich nur tag-Beschreibungen gefunden, nicht aber die richtige Schreibweise. Da wird von "2.0" und "3.0_BETA" geschrieben, aber das sieht jeder das man die Tag's so nicht schreibt...
 
Ich habs gefunden, hier die Antwort (wegen der Vollständigkeit)

quarzsnoopy schrieb:
mmh, welche CVS-tag's muss ich denn für die "3.0_BETA" angeben? Ich habe es mal mit "netbsd-3" versucht, hab aber keine Ahnung was ich mir da gezogen hab...
was bedeuten die folgenden tag's:

"netbsd-3" => ?
"netbsd-2" => ?
"netbsd-2-0" => ?

netbsd-2-0-2 hab ich mir bis jetzt immer gesaugt, wenn ich es brauchte. Das kenne ich auch, das ist "NetBSD 2.0.2 RELEASE + Sicherheitspatches", aber was sind die anderen?
Ist "netbsd-2" oder "netbsd-2-0" die "STABLE"???

Auf der NetBSD-Seite (http://www.netbsd.org/Releases/release-map.html) hab ich nur tag-Beschreibungen gefunden, nicht aber die richtige Schreibweise. Da wird von "2.0" und "3.0_BETA" geschrieben, aber das sieht jeder das man die Tag's so nicht schreibt...
Zum Vergrößern anklicken....

http://cvsweb.netbsd.org/bsdweb.cgi/src/doc/BRANCHES?rev=HEAD&content-type=text/x-cvsweb-markup


Branch: netbsd-2-0
Description: Originally the NetBSD 2.0 release branch and now the branch
tracking security/critical fixes for the NetBSD 2.0 series

Branch: netbsd-2
Description: The NetBSD 2 release branch

Branch: netbsd-3
Description: The NetBSD 3 release branch
 
Heyho,

ich weiß, dass Thema ist wohl schon längst vergessen, aber ich habe mal eben schnell ein Skript gebastelt, mit welchem man seine ganzen Pakete in einem Ruck neu kompilieren kann. Zusätzlich wird vorher geprüft, ob das Paket schon gebaut worden ist (man kann also das ganze zwischendurch auch stoppen). Vorraussetzung hierfür: pkg_comp

Code: 
pkg_info | awk '{print $1}' | while read PAKETNAME; do  ORIGIN=`cat /usr/pkgsrc/INDEX | grep ^$PAKETNAME | awk -F '|' '{print $2}'`; ORIGINVER=`cat /usr/pkgsrc/INDEX | grep ^$PAKETNAME | awk -F '|' '{print $1}'`; if [ ! -f /usr/pkg_comp/pkgs/All/$ORIGINVER.tgz ]; then pkg_comp build $ORIGIN;fi; done

Ich denke mal, es wird allen helfen können ;) Habe dazu auch ein paar Schnippsel aus dem Thread hier genommen und erweitert. Und das schönste ist: Das Skript tut seinen Dienst. Sobald die letzten Pakete hier fertig sind, widme ich dem Problem: Alle Pakete in einem Ruck upgraden (das wird aber wohl kein Problem sein *gg*).

BTW: Die Verzeichnisse der Umgebung anpassen (ist aber auch logisch oder?)

cheers
pierre
 
pierre schrieb:
Heyho,

ich weiß, dass Thema ist wohl schon längst vergessen, aber ich habe mal eben schnell ein Skript gebastelt, mit welchem man seine ganzen Pakete in einem Ruck neu kompilieren kann.
Zum Vergrößern anklicken....
Nein, noch nicht vergessen! Ich habe zwar eine Lösung aber für verbesserungsvorschläge bin ich immer Dankbar. :)


pierre schrieb:
Zusätzlich wird vorher geprüft, ob das Paket schon gebaut worden ist (man kann also das ganze zwischendurch auch stoppen). Vorraussetzung hierfür: pkg_comp

Code: 
pkg_info | awk '{print $1}' | while read PAKETNAME
do
ORIGIN=`cat /usr/pkgsrc/INDEX | grep ^$PAKETNAME | awk -F '|' '{print $2}'`
ORIGINVER=`cat /usr/pkgsrc/INDEX | grep ^$PAKETNAME | awk -F '|' '{print $1}'`
if [ ! -f /usr/pkg_comp/pkgs/All/$ORIGINVER.tgz ]
then
pkg_comp build $ORIGIN
fi
done
Zum Vergrößern anklicken....
Dieses Script ist zwar nicht so flexibel, wie meine im Moment verwendete Lösung, sieht aber sehr interessant aus. Besonder lehrreich für mich, ist natürlich, wie "pkg_comp" angewendet wird. Bis jetzt habe ich immer das alte (aber zuverlässige) "Sandkasten-Script" aus pkgsrc verwendet.


pierre schrieb:
Ich denke mal, es wird allen helfen können ;) Habe dazu auch ein paar Schnippsel aus dem Thread hier genommen und erweitert. Und das schönste ist: Das Skript tut seinen Dienst. Sobald die letzten Pakete hier fertig sind, widme ich dem Problem: Alle Pakete in einem Ruck upgraden (das wird aber wohl kein Problem sein *gg*).

BTW: Die Verzeichnisse der Umgebung anpassen (ist aber auch logisch oder?)

cheers
pierre
Zum Vergrößern anklicken....

Ich werde es die Tage mal ausprobieren... :D
 
da fehlt doch noch was...

pierre schrieb:
....
Code: 
pkg_info | awk '{print $1}' | while read PAKETNAME
do  ORIGIN=`cat /usr/pkgsrc/INDEX | grep ^$PAKETNAME | awk -F '|' '{print $2}'`
ORIGINVER=`cat /usr/pkgsrc/INDEX | grep ^$PAKETNAME | awk -F '|' '{print $1}'`
if [ ! -f /usr/pkg_comp/pkgs/All/$ORIGINVER.tgz ]
then
pkg_comp build $ORIGIN
fi
done
....
Zum Vergrößern anklicken....

Wenn isch das hier so richtig sehe, lautet ein brauchbarer Befehl:
> pkg_comp build devel/pcre

da meckert er bei mir aber über ein nicht vorhandenes Verzeichnis und einer nicht vorhandenen Config-Datei, ...hab ich dan angelegt (leere Datei) und nun geht es immer noch nicht.

Jetzt hab ich mal die man-Page durchgesehen und den Befehl abgeschickt:
> pkg_comp auto devel/pcre

jetzt will er alle Sets um ein neues System aufzusetzen...?

Das ist doch nicht etwa wirklich nötig für eine Sandbox, oder?

Wenn "Ja", dann solltest Du die nötigen Vorbereitungen für Dein Script aber auch in einer kurzen Beschreibung kund tun...!
Oder die verwendete "default.conf" für die Option "build" mit posten.
:D
 
Fehler bei dem update script

Hi....

Weiter oben wurde ein Script vorgestellt, welches das einfache updaten/upgraden möglich macht.

Danke an den Autor, der da echt gute Arbeit geleistet hat..

Leider findet das Script bei mir die pkgchk.conf nicht...

269 /usr/sandbox/pkgchk.conf
cat: pkgchk.conf: No such file or directory

Im Script habe ich:

# ohne Beruecksichtigung von ${PKGSRCDIR}/pkgchk.conf
pkg_chk -iC ${SANDKISTE}/${PKGCHKCONF}
#
# mit Beruecksichtigung von ${PKGSRCDIR}/pkgchk.conf
#pkg_chk -cC ${SANDKISTE}/${PKGCHKCONF}
#
# ein gezieltest Package
#echo "misc/openoffice" >> ${SANDKISTE}/${PKGCHKCONF}

Es wird also -i ausgeführt. Eine /usr/pkgsrc/pkgchk.conf existiert nicht, brauche ich SO ja auch nicht.

Es muss also in /usr/sandbox eine pkgchk.conf angelegt werden, das macht doch dieses Kommando:
pkg_chk -iC ${SANDKISTE}/${PKGCHKCONF}

Leider funktioniert es nicht... Es wird nichts angelegt!

Auch wenn ich das Kommando ausserhalb des Scripts ausführe.
 
salex schrieb:
Hi....

Weiter oben wurde ein Script vorgestellt, welches das einfache updaten/upgraden möglich macht.

Danke an den Autor, der da echt gute Arbeit geleistet hat..

Leider findet das Script bei mir die pkgchk.conf nicht...

269 /usr/sandbox/pkgchk.conf
cat: pkgchk.conf: No such file or directory

Im Script habe ich:

# ohne Beruecksichtigung von ${PKGSRCDIR}/pkgchk.conf
pkg_chk -iC ${SANDKISTE}/${PKGCHKCONF}
#
# mit Beruecksichtigung von ${PKGSRCDIR}/pkgchk.conf
#pkg_chk -cC ${SANDKISTE}/${PKGCHKCONF}
#
# ein gezieltest Package
#echo "misc/openoffice" >> ${SANDKISTE}/${PKGCHKCONF}

Es wird also -i ausgeführt. Eine /usr/pkgsrc/pkgchk.conf existiert nicht, brauche ich SO ja auch nicht.

Es muss also in /usr/sandbox eine pkgchk.conf angelegt werden, das macht doch dieses Kommando:
pkg_chk -iC ${SANDKISTE}/${PKGCHKCONF}

Leider funktioniert es nicht... Es wird nichts angelegt!

Auch wenn ich das Kommando ausserhalb des Scripts ausführe.
Zum Vergrößern anklicken....

Das Script nutze ich schon lange nicht mehr. Als ich pkg_comp ausprobiert hatte fand ich es besser und nutze es jetzt.


Ganz kurz gesagt, macht das alte Script aus Beitrag "Nr. 41" folgendes:

################################################################################
### Mit dem "mksandbox"-Script in der Sandkiste
###--------------------------------------------------------------------------###
###
### "mk/bulk/mksandbox" arbeitet mit null-mountpoints aus dem aktuellen System:
###
### # Sandkiste bauen
### /usr/pkgsrc/mk/bulk/mksandbox --pkgsrc=/usr/pkgsrc --src=/usr/src --xsrc=/usr/xsrc /usr/sandbox
###
### # Sandkiste nutzen
### /usr/sandbox/sandbox mount
### chroot -u root /usr/sandbox /bin/sh -c "cd /usr/pkgsrc/sysutils/mc/ && make package clean-depends clean"
### /usr/sandbox/sandbox umount
###
### # Sandkiste löschen
### rm -fr /usr/sandbox
###
################################################################################


UND mit pkg_comp kann man es z.B. so machen:

:D

################################################################################
### Mit "pkg_comp" in der Sandkiste
###--------------------------------------------------------------------------###
###
### "pkgtools/pkg_comp" benötigt die kompletten "Release-Sets" und wird so
### aufgerufen:
###
###==========================================================================###
### Quellen holen/updaten
###--------------------------------------------------------------------------###
###
### zuerst braucht man die kompletten Quellen (NetBSD 3.x):
### cd /usr
### rm -fr obj
### mkdir -p obj
### cvs -q -d anoncvs@anoncvs.netbsd.org:/cvsroot checkout -PAR pkgsrc
### cvs -q -d anoncvs@anoncvs.netbsd.org:/cvsroot checkout -rnetbsd-3 -PAR src
### cvs -q -d anoncvs@anoncvs.netbsd.org:/cvsroot checkout -rnetbsd-3 -PAR xsrc
### cd pkgsrc && make index
###
###
### wenn schon Quellen da sind, werden wir sie aktuallisieren (NetBSD 3.x):
### cd /usr
### cvs -q -d anoncvs@anoncvs.netbsd.org:/cvsroot update -PARd pkgsrc
### cvs -q -d anoncvs@anoncvs.netbsd.org:/cvsroot update -rnetbsd-3 -PARd src
### cvs -q -d anoncvs@anoncvs.netbsd.org:/cvsroot update -rnetbsd-3 -PARd xsrc
### cd pkgsrc && make index
###
###
###==========================================================================###
### Sets bauen
###--------------------------------------------------------------------------###
###
### jetzt können wir die Sets bauen:
### vi /etc/mk.conf (siehe auch "/usr/src/BUILDING")
### PAGER=less
### MKUNPRIVED=yes
### MAKEOBJDIRPREFIX=/var/tmp/build
### RELEASEDIR=/var/tmp/release
### MKX11=yes
### ACCEPTABLE_LICENSES+=lame-license
### ACCEPTABLE_LICENSES+=skype-license
### PKG_OPTIONS.bash=multibyte static
### PKG_SUFX=".tbz"
### CVSUP_STATIC=yes
###
### cd /usr/src/
### ./build.sh tools kernel=GENERIC releasekernel=GENERIC release sets
###
###==========================================================================###
###
### Wenn die gesaugten Quellen aktueller sind als das installierte System,
### sollte man jetzt ein Binär-Update durchführen, um die Sandkiste und das
### Basis-System in gleicher Version zu haben.
###
###==========================================================================###
### pkg_comp aktivieren
###--------------------------------------------------------------------------###
###
### jetzt können wir pkg_comp konfigurieren:
### cd /usr/pkgsrc/pkgtools/pkg_comp && make package clean-depends clean
### pkg_comp maketemplate
### vi /root/pkg_comp/default.conf
### DEPENDS_TARGET="package"
### BINPKG_SITES="#defined"
### MKCONF_VARS="$MKCONF_VARS $DEPENDS_TARGET $BINPKG_SITES"
### DISTRIBDIR=/var/tmp/release/i386
### REAL_PKGSRC=/usr/pkgsrc
### SETS_X11="xbase.tgz xcomp.tgz xetc.tgz xfont.tgz xserver.tgz"
### EXTRAMK="/etc/mk.conf"
### ROOTSHELL="/bin/ksh"
###
### damit die fertigen Packages unter "/usr/pkgsrc/packages" abgelegt werden:
### vi /etc/mk.conf
### DEPENDS_TARGET=package
### UPDATE_TARGET=package
### PKG_SUFX=".tbz"
### PAGER=less
### MAKEOBJDIRPREFIX=/var/tmp/build
### RELEASEDIR=/var/tmp/release
### MKX11=yes
### CVSUP_STATIC=yes
###
###==========================================================================###
### mit pkg_comp das Package bauen
###--------------------------------------------------------------------------###
###
### jetzt können wir die Packages mit pkg_comp in einer Sandkiste bauen:
### pkg_comp auto $ORIGIN
###
###
###==========================================================================###
### mit pkg_comp die Packages bauen
###--------------------------------------------------------------------------###
###
### man kann auch mehrere Package-Angaben hintereinander angeben:
### pkg_comp auto $ORIGIN1 $ORIGIN2 $ORIGIN3 $ORIGIN4
###
################################################################################



Mein aktuelles Script stelle ich hier nicht rein, weil ich zuviele selbstgeschrieben "etc"-Dateien darin verwende. Das würde nur unnötig verwirren.

:D

Die veralteten Packages finde ich so raus:


#!/bin/sh
################################################################################
###
### Zeigt alle ORIGIN, der veralteten installierten Packages.
###
################################################################################

SH=`which sh`

### Liste der veralteten Packages erstellen
pkg_chk -i | cut -d':' -f1 | sed 's/.*/^&/' > /tmp/pkgchk.conf-1

### Liste der origin von den veralteten Packages erstellen
cat /usr/pkgsrc/INDEX | grep -f /tmp/pkgchk.conf-1 | awk -F'|' '{print $2}' | cut -d':' -f1 | (while read PKGNAME
do
if [ ! -f /usr/pkgsrc/packages/${PKGNAME}.tbz ] ; then
echo "${PKGNAME}"
fi
done)
################################################################################


:D
 
Hi..


Super Sache, doch wenn ich das release baue, dann werden keine x***.tgz erstellt... also kein xcomp.tgz, kein xbase.tgz...

und wenn ich diese vom ftp hole und in das verzeichniss kopiere
scheint erstmals alles zu funktionieren.

ich starte das ganze mal mit pkg_comp auto unrar
doch dann will er x11-links installieren, und das endet in dieser meldung:

Creating package /pkg_comp/packages/All/digest-20050731.tbz
Using SrcDir value of /usr/pkg
Registering depends:.
===> clean [digest-20050731] ===> Cleaning for digest-20050731
PKG_COMP ==> Unmounting sandboxed filesystems
PKG_COMP ==> Mounting sandboxed filesystems
PKG_COMP ==> Installing new `pkg-vulnerabilities' file
/usr/pkgsrc/distfiles/pkg-vulnerabilities not found.
PKG_COMP ==> Checking if pkg_install is up to date
PKG_COMP ==> Building and installing pkgtools/x11-links
===> package [x11-links-0.26] ===> x11-links-0.26 requires X headers to be installed
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/pkgtools/x11-links
===> clean [x11-links-0.26] ===> Cleaning for x11-links-0.26
PKG_COMP ==> Unmounting sandboxed filesystems
PKG_COMP ==> Build error summary
Build failed for:
pkgtools/x11-links
pkg_comp: invalid packages: unrar

gut, das er das package unrar nicht findet ist nicht schlimm, aber der Fehler mit den X Headers macht mich rätselhaft
 
salex schrieb:
Hi..


Super Sache, doch wenn ich das release baue, dann werden keine x***.tgz erstellt... also kein xcomp.tgz, kein xbase.tgz...

und wenn ich diese vom ftp hole und in das verzeichniss kopiere
scheint erstmals alles zu funktionieren.
Zum Vergrößern anklicken....

### Sets bauen
> vi /etc/mk.conf
PAGER=less
MKUNPRIVED=yes
MAKEOBJDIRPREFIX=/var/tmp/build
RELEASEDIR=/var/tmp/release
MKX11=yes
ACCEPTABLE_LICENSES+=lame-license
ACCEPTABLE_LICENSES+=skype-license
PKG_OPTIONS.bash=multibyte static
PKG_SUFX=".tbz"
CVSUP_STATIC=yes


salex schrieb:
ich starte das ganze mal mit pkg_comp auto unrar
doch dann will er x11-links installieren, und das endet in dieser meldung:

Creating package /pkg_comp/packages/All/digest-20050731.tbz
Using SrcDir value of /usr/pkg
Registering depends:.
===> clean [digest-20050731] ===> Cleaning for digest-20050731
PKG_COMP ==> Unmounting sandboxed filesystems
PKG_COMP ==> Mounting sandboxed filesystems
PKG_COMP ==> Installing new `pkg-vulnerabilities' file
/usr/pkgsrc/distfiles/pkg-vulnerabilities not found.
PKG_COMP ==> Checking if pkg_install is up to date
PKG_COMP ==> Building and installing pkgtools/x11-links
===> package [x11-links-0.26] ===> x11-links-0.26 requires X headers to be installed
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/pkgtools/x11-links
===> clean [x11-links-0.26] ===> Cleaning for x11-links-0.26
PKG_COMP ==> Unmounting sandboxed filesystems
PKG_COMP ==> Build error summary
Build failed for:
pkgtools/x11-links
pkg_comp: invalid packages: unrar

gut, das er das package unrar nicht findet ist nicht schlimm, aber der Fehler mit den X Headers macht mich rätselhaft
Zum Vergrößern anklicken....

Da musst Du die "X11"-Geschichte auch aktivieren!

### in der pkg_comp-Konfiguration
> vi /root/pkg_comp/default.conf
DEPENDS_TARGET="package"
BINPKG_SITES="#defined"
MKCONF_VARS="$MKCONF_VARS $DEPENDS_TARGET $BINPKG_SITES"
DISTRIBDIR=/var/tmp/release/i386
REAL_PKGSRC=/usr/pkgsrc
SETS_X11="xbase.tgz xcomp.tgz xetc.tgz xfont.tgz xserver.tgz"
EXTRAMK="/etc/mk.conf"
ROOTSHELL="/bin/ksh"


### Sandkiste mit dem "alten" Script bauen
/usr/pkgsrc/mk/bulk/mksandbox --pkgsrc=/usr/pkgsrc --src=/usr/src --xsrc=/usr/xsrc /usr/sandbox

Das setzt natürlich vorraus, dass in Deinem System X11 auch installiert ist!
:D
 
Zuletzt bearbeitet:
...darann hab ich ja garnicht gedacht...

salex schrieb:
Hi.

Ja, X ist installiert, allerdings Xorg vom pkgsrc, nicht das systemeigene.
Zum Vergrößern anklicken....

Kann damit zusammen hängen... :grumble:
Ich habe nur das Systemeigene X11 drauf und da hat alles wunderbar funktioniert!

Xorg aus PKGSRC will ich mir auch irgendwann noch installieren, da die UTF-8-Unterstützung in XFree86 schlechter sein soll.
 
na subba...

wie soll ich denn jetzt meine packages updaten?

ansonsten habe ich auch noch das problem, das pkg_comp meine pkg_vulnerabilities wo komplet anderes sucht, und selbst wenn ich sie richtig verlinke, heißt es, das er sie nicht findet.

Ausserdem sagt er, das /usr/pkg/bin/ftp nicht existiert, was nicht wahr ist.

Also 3 Probleme... Wenn ich die irgendwie beseitigen kann, würde es klappen.
 
...nicht gleich resignieren!!!

salex schrieb:
na subba...

wie soll ich denn jetzt meine packages updaten?

ansonsten habe ich auch noch das problem, das pkg_comp meine pkg_vulnerabilities wo komplet anderes sucht, und selbst wenn ich sie richtig verlinke, heißt es, das er sie nicht findet.
Zum Vergrößern anklicken....
Die Vulnerabilities lasse ich grundsätzlich weck, weil ich festgestellt habe, dass es Programme gibt, die IMMER bekannte Fehler enthalten. Mit dieser Vulnerabilitie-Liste würde er dieses Programm fehlerhafte Programm (z.B. den Netscape) nicht installieren, auch wenn die alte Version viele und die neue Version wenige Löcher hat...


salex schrieb:
Ausserdem sagt er, das /usr/pkg/bin/ftp nicht existiert, was nicht wahr ist.

Also 3 Probleme... Wenn ich die irgendwie beseitigen kann, würde es klappen.
Zum Vergrößern anklicken....
Der Rest Deiner Probleme sieht nach falschem, kaputtem, unvollständigem Pfad aus!!!
Ich erinnere mich, das man früher die Suchpfade unter "/usr/pkg/" von Hand ergänzen musste, jetzt eigentlich nicht mehr.

mach mal ein
> echo $PATH

...da sollte irgendwo ein ":/usr/pkg/bin:" mit drin stehen, wenn nicht könnte das schon dein Problem beheben (oder einen Teil Deiner Probs). :D
 
...zur Dokumentation...

Sollten die Anweisungen unten auf Seite 4 zu Fehlern führen, dann erstmal alle Einträge aus den beiden Konfigurationsdateien raus lassen, die nicht unbedingt nötig sind!

hier nur das eintragen:
> vi /etc/mk.conf
MAKEOBJDIRPREFIX=/var/tmp/build
RELEASEDIR=/var/tmp/release
MKX11=yes
PKG_SUFX=".tbz"

hier nur das eintragen:
> vi /root/pkg_comp/default.conf
DEPENDS_TARGET="package"
DISTRIBDIR=/var/tmp/release/i386
REAL_PKGSRC=/usr/pkgsrc
SETS_X11="xbase.tgz xcomp.tgz xetc.tgz xfont.tgz xserver.tgz"
ROOTSHELL="/bin/ksh"


* Niemals mehrere Dinge gleichzeitig ändern, sonst weiss man nicht wrann es gelegen hat!
* Niemals die Sets mischen, d.h. einen teil selber bauen und die anderen saugen; sondern entweder alle saugen oder alle selber bauen!

Systematisches vorgehen wirkt Wunder!
:D
 
Noch einen Schritt weiter

Ich baue gerade an einer eigenen "Automatik" für die Paketaktualisierung und bin gerade bei einer Frage angelangt, die meiner Meinung nach hier gut mit reinpassen könnte.

Hintergrund: Ich möchte immer das aktuelle pkgsrc-Release auf dem Rechner haben - automatisch (!). Es soll direkt aus dem CVS ausgechecked werden.

Hierfür muß ich nur leider das aktuelle Tag vom Branch wissen. Gibt es eine technische Lösung herauszubekommen, welches Release-Tag gerade das aktuelle ist ?

Noch einige Anmerkungen:

- Nein, current ist nicht die gewünschte Lösung !
- Ich bin kein CVS-Profi.
- Es soll möglichst mit "Hausmitteln" realisiert werden (sprich: *.sh).

Meine aktuelle Lösung:

Ich habe ein kleines Shell-Skript geschrieben, daß aus dem Systemdatum das Release-Tag ermittelt. Da es gerne mal zu verzögerungen kommt mit dem Release, habe ich einen Monat Puffer eingebaut, also pkgsrc-2005Q3 wäre bei mir ab November 2005 auf's System gewandert, nicht Oktober. Ist das schon die eleganteste Lösung ? Die NetBSD-Website automatisiert nach news zu scannen, wo "pkgsrc*released" vorkommt, ist mir derzeit etwas zu oversized als Lösung.

Was meint Ihr ?
 
Hast du nicht mal geschrieben, das du dass NetBSD 1.6 Buch von CUL hast?

Da steht es so drin:

cul schrieb:
Update:
Code: 
setenv CVSROOT anoncvs@aononcvs.netbsd.org:/cvsroot
setenv CVS_RSH ssh
cd /usr/pkgsrc
cvs -q -z3 update -P -d
Zum Vergrößern anklicken....

ich hab es bisher erst einmal auf diesen Weg gemacht, da es sehr langwierig ist. Musste damals die Befehle ein wenig anpassen, da ich bash user bin. Dort muss man mit export statt mit setenv die globalen Variablen festlegen
 
SierraX schrieb:
Hast du nicht mal geschrieben, das du dass NetBSD 1.6 Buch von CUL hast?

Da steht es so drin:



ich hab es bisher erst einmal auf diesen Weg gemacht, da es sehr langwierig ist. Musste damals die Befehle ein wenig anpassen, da ich bash user bin. Dort muss man mit export statt mit setenv die globalen Variablen festlegen
Zum Vergrößern anklicken....

Das Buch habe ich tatsächlich und da steht auch das drin was Du geschrieben hast, aber ...

... wenn ich einfach nur ein cvs update mache, dann bringe ich immer nur den Branch auf den neuen Stand, den ich zuletzt ausgechecked hatte. Also wenn ich pkgsrc-2005Q2 auf dem System habe und jetzt ein update darauf machte, dann hätte ich weiterhin pkgsrc-2005Q2, ich will aber zu diesem Zeitpunkt auf pkgsrc-2005Q3 wechseln ! Sobald ein pkgsrc-Release durch ein neueres abgelöst wird, gibt es ja wohl kaum noch Arbeiten daran, also keine gänzlich neuen PKGs, keine neuen Versionsnummern, etc. Verstehst Du ? Oder habe ich irgendwas nicht verstanden ?
 
Was draufsteht ist doch relativ egal. Ich hab es so verstanden. Es wird ein fester Stand geladen und das muesste der aus current/tar-files sein. Und von da aus wird der stand upgedatet. die quartals releases dienen nur als package collection grundlage. Wer aber immer den aktuellen stand haben will macht es so wie es im code steht.
Q3 ist alles andere als Aktuell

Sorry hab teilweise nicht richtig gelesen. Die Packagesource aendert sich laut aussage Buch und Lindloff fast taeglich. Pakete und Ports kommen dazu (also z.B. am 11.10. funktioniert nicht fuer Sparc64 ab dem 15.10 schon). Du kannst ja sogar selbst sowas anlegen und einreichen. Da wird nicht gewartet bis das laufende 1/4 Jahr rum ist.
 
Zuletzt bearbeitet:
CAMISOLITE schrieb:
...
- Es soll möglichst mit "Hausmitteln" realisiert werden (sprich: *.sh).
Zum Vergrößern anklicken....
Das ist auch mein Motto! :D


CAMISOLITE schrieb:
Meine aktuelle Lösung:

Ich habe ein kleines Shell-Skript geschrieben, daß aus dem Systemdatum das Release-Tag ermittelt. Da es gerne mal zu verzögerungen kommt mit dem Release, habe ich einen Monat Puffer eingebaut, also pkgsrc-2005Q3 wäre bei mir ab November 2005 auf's System gewandert, nicht Oktober. Ist das schon die eleganteste Lösung ? Die NetBSD-Website automatisiert nach news zu scannen, wo "pkgsrc*released" vorkommt, ist mir derzeit etwas zu oversized als Lösung.

Was meint Ihr ?
Zum Vergrößern anklicken....
Also, ich würde sagen die "NetBSD-Website" zu durchsuchen ist auch nicht sehr elegant, da die Ankündigungen mit den Veröffentlichungen nicht immer syncron laufen müssen (hab schon bis zu zwei Tage Differenz gesehen).

Ich würde: "Kontrollier genau das Objekt, was Du begehrst!".
Also hol Dir diesen Unterverzeichniszweig jede Woche oder alle zwei Wochen oder so per CVS und führe darin dieses Kommando aus:
Code: 
bash-3.00# cd /usr/src/sys/conf
bash-3.00# sh osrelease.sh
3.0_BETA
Das sollte genau Deine Frage beantworten.

Ich weiss nicht genau wie das Kommando arbeitet, vielleicht muss alles neu sein (glaub ich aber nicht), dann ist es besser cvsup aus PKGSRC zu verwenden (wegen dem Traffik).... probier es einfach mal aus. :D
 
Verständnisproblem

SierraX schrieb:
Was draufsteht ist doch relativ egal. Ich hab es so verstanden. Es wird ein fester Stand geladen und das muesste der aus current/tar-files sein. Und von da aus wird der stand upgedatet. die quartals releases dienen nur als package collection grundlage. Wer aber immer den aktuellen stand haben will macht es so wie es im code steht.
Q3 ist alles andere als Aktuell

Sorry hab teilweise nicht richtig gelesen. Die Packagesource aendert sich laut aussage Buch und Lindloff fast taeglich. Pakete und Ports kommen dazu (also z.B. am 11.10. funktioniert nicht fuer Sparc64 ab dem 15.10 schon). Du kannst ja sogar selbst sowas anlegen und einreichen. Da wird nicht gewartet bis das laufende 1/4 Jahr rum ist.
Zum Vergrößern anklicken....

Ich glaube wir reden aneinander vorbei oder ich peil hier was grundlegendes nicht.

Du sprichst von current ! Da kann man das sicher einfach machen, aber da wird auch täglich dran gearbeitet. Schließlich gibt es dann für mich keine (billige) Möglichkeit herauszufinden, an welchem Tag ein checkout günstig wäre (weil zufällig mal alles funktioniert).

Daher möchte ich das Release. Nach meinem Kenntnisstand läuft das so ab:
- An current wird ständig weiterentwickelt.
- Einmal pro Quartal gibt es einen Freeze von current für z.B. zwei Wochen, da gibt's nur Bug-Fixes bis die Bulk-Builds vernünftig laufen.
- Sind die Bulk-Builds erfolgreich wird ein Release von der gefreezten current-Linie als pkgsrc-yyyyQn abgezweigt.
- Der Freeze wird aufgehoben und in current wird munter weitergemacht während pkgsrc-yyyyQn unverändert bleibt - außer bei wichtigen Bugs/Sicherheitslücken.

Das Release ist somit ein Snapshot, bei dem man davon ausgehen kann, daß er auf jeden Fall (weitestgehend) funktioniert. current ist hingegen Glückssache/Tagesform. Mal davon abgesehen, daß täglich Pakete bauen in meinen Augen Vergeudung von Rechnerleistung ist, möchte ich mir das auch nicht so häufig antun. Einmal pro Quartal ist völlig okay.
 
quarzsnoopy schrieb:
Ich würde: "Kontrollier genau das Objekt, was Du begehrst!".
Also hol Dir diesen Unterverzeichniszweig jede Woche oder alle zwei Wochen oder so per CVS und führe darin dieses Kommando aus:
Code: 
bash-3.00# cd /usr/src/sys/conf
bash-3.00# sh osrelease.sh
3.0_BETA
Das sollte genau Deine Frage beantworten.
Zum Vergrößern anklicken....

Sehe ich nicht so.

quarzsnoopy schrieb:
Ich weiss nicht genau wie das Kommando arbeitet, vielleicht muss alles neu sein (glaub ich aber nicht), dann ist es besser cvsup aus PKGSRC zu verwenden (wegen dem Traffik).... probier es einfach mal aus. :D
Zum Vergrößern anklicken....

osrelease.sh macht ein grep auf eine Header-Datei und ermittelt so die OS-Version. Es gibt ein simples "2.0.2" aus - nichts anderes als ein uname -r.

1. Es ermittelt das OS-Release. Interessiert an der Stelle hier nicht, es geht um das pkgsrc-Release.
2. Wenn ich das Skript umschreiben würde, wonach sollte ich in pkgsrc grepen ?

Ihr habt schon verstanden, daß ich mit Release nicht das NetBSD-Release meine ???
 
Zuletzt bearbeitet:
CAMISOLITE schrieb:
...
Nach meinem Kenntnisstand läuft das so ab:
- An current wird ständig weiterentwickelt.
- Einmal pro Quartal gibt es einen Freeze von current für z.B. zwei Wochen, da gibt's nur Bug-Fixes bis die Bulk-Builds vernünftig laufen.
- Sind die Bulk-Builds erfolgreich wird ein Release von der gefreezten current-Linie als pkgsrc-yyyyQn abgezweigt.
- Der Freeze wird aufgehoben und in current wird munter weitergemacht während pkgsrc-yyyyQn unverändert bleibt ....
Zum Vergrößern anklicken....

So habe ich dies im Prinzip auch verstanden. Im Prinzip suchst du dann ja wohl einen (CVS)-Befehl der dir alle TAGS des Repository liefert? Das Ergebniss müßte man dann noch auf einen neu(er)en TAG prüfen und diesen dann auslesen...

Schaut man sich mal das cvsweb an hat man ja im Prinzip eine Darstellungsform für die TAGS (untere Bildschirmrand). Jetzt wäre halt zu klären ob es einen (CVS)-Befehl gibt welcher diese Ausgabe direkt liefert ("Befehlszeile"), oder ob die Webausgabe mittel weiterer Hilfsmittel erstellt/aufbereitet wurde, als noch irgendwelche "Scriptaufgaben" nötig sind/wären... -> Studium der cvs-Befehle?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben