# [really solved]Warum will portage busybox????

## dakjo

Hi,

ich hab hier nen Server mit Gentoo. Soweit auch alles Ok, nur will er seit heute plötzlich busybox beim worldupdate installieren?

```

mail boot # emerge world -puv

These are the packages that I would merge, in order:

Calculating world dependencies ...done!

[ebuild  N    ] sys-apps/busybox-1.00-r4  -debug -floppyboot -make-symlinks -netboot -savedconfig -static 0 kB 

Total size of downloads: 0 kB
```

Ich mein OK. Aber selbst bei 

```
mail boot # emerge world -pUv

These are the packages that I would merge, in order:

Calculating world dependencies ...done!

[ebuild  N    ] sys-apps/busybox-1.00-r4  -debug -floppyboot -make-symlinks -netboot -savedconfig -static 0 kB 

Total size of downloads: 0 kB

```

Nagut soll er es halt installieren:

```

mail boot # emerge world -u 

Calculating world dependencies ...done!

>>> emerge (1 of 1) sys-apps/busybox-1.00-r4 to /

>>> md5 files   ;-) ChangeLog

>>> md5 files   ;-) busybox-1.00-r1.ebuild

>>> md5 files   ;-) metadata.xml

.....

i686-pc-linux-gnu-strip --remove-section=.note --remove-section=.comment busybox

i686-pc-linux-gnu-gcc -static -o busybox -Wl,--start-group /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/applets/applets.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/archival/archival.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/archival/libunarchive/libunarchive.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/coreutils/coreutils.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/console-tools/console-tools.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/debianutils/debianutils.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/editors/editors.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/findutils/findutils.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/init/init.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/miscutils/miscutils.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/modutils/modutils.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/networking/networking.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/networking/libiproute/libiproute.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/networking/udhcp/udhcp.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/procps/procps.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/loginutils/loginutils.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/shell/shell.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/sysklogd/sysklogd.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/util-linux/util-linux.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/libpwdgrp/libpwdgrp.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/coreutils/libcoreutils/libcoreutils.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/libbb/libbb.a /var/tmp/portage/busybox-1.00-r4/work/busybox-1.00/e2fsprogs/e2fsprogs.a -lm -lcrypt -lcrypt -Wl,--end-group

!!! ERROR: sys-apps/busybox-1.00-r4 failed.

!!! Function src_compile, Line 139, Exitcode 2

!!! (no error message)

!!! If you need support, post the topmost build error, NOT this status message.

```

Tja ... und nu?

----------

## TheCurse

Selbes Problem hier, und seit ein paar Tagen noch eines:

Ich habe beim letzten world-update nicht aufgepasst und jetzt einige (sehr) alte gnome sachen drauf. bei einem emerge -etpv world werden diese nicht angezeigt aber bei einem emerge depclean auch nicht entfernt...

----------

## pir187

servus,

habe mich auch schon gewundert, wieso dieses paket eingespielt werden soll.

vielleicht gibt es ja einen grund dafür - schön wäre es.

einer könnte sein, daß busybox z.b. 

```
addgroup, adduser
```

 usw. enthält. ist das schon der grund?

viele grüße, pir187

----------

## dakjo

Na ich glaube mal nicht, weil das ja nicht gelinkt wird.

----------

## Mailman04

Mach doch mal ein 

```
emerge -puvD --tree world
```

 Mit dem 

```
--tree
```

 solltest du dann sehen, welches Paket busybox als Abhängigkeit installieren will.

----------

## TheCurse

Das ist ja das Problem bei der Sache, anscheinen will kein Paket busybox als Abhängigkeit...

Meine Gnomesachen tauchen dabei übrigens gar nicht auf...

----------

## Genone

busybox ersetzt sash als Rescue Shell.

----------

## dakjo

Toll, wenn das jetzt wenigstens stable wäre, also ich mein so qa is ja wohl mitlerweile nix mehr hier bei gentoo .....

Wie ich sowas hasse ...

----------

## schachti

 *dakjo wrote:*   

> 
> 
> Nagut soll er es halt installieren:
> 
> ```
> ...

 

Hier das selbe Problem auf 7 unterschiedlichen Rechnern.  :Crying or Very sad: 

----------

## dakjo

```
mail # cat /etc/portage/package.mask 

=sys-apps/busybox-1.00-r4

```

und schon geht es

----------

## Mailman04

Dann warte ich mit dem nächsten Update erst mal  :Very Happy: 

----------

## dakjo

Da war wohl jemand etwas übereifrig mit dem stabeln.. vor allem ohne Changelog und qa also ... tztztzt

----------

## TheCurse

Besonders weil sash beim depclean schon entfernt wurde und busybox noch nicht drauf ist.....

----------

## dakjo

Genau das macht so den sinn.... ich kann doch sowas nicht umstellen und dann dabei so brOken shit verwenden.

So wird Gentoo nie gross.

----------

## Genone

 *dakjo wrote:*   

> Genau das macht so den sinn.... ich kann doch sowas nicht umstellen und dann dabei so brOken shit verwenden.
> 
> So wird Gentoo nie gross.

 

Konkrete Verbesserungsvorschläge?

----------

## dakjo

Ebuilds vorher mal auf x86 Maschinen zu testen. Wie ich festgestellt habe funktioniert es auf ~x86 Maschinen.

----------

## b3cks

Just for info: Emergen mit x86 war kein Problem.

----------

## TheCurse

Also bei meinem Mischsystem ging es nicht.

----------

## dakjo

Just for Info: Ich hab das jetzt auf 9 Rechnern mit Gentoo getestet. Auf nur einem und zwar der mit ~x86 hat es funktioniert.

----------

## Kuhrscher

Bei mir (amd64) funktionierts auch nicht...

----------

## pir187

Wieso ist der Thread jetzt als solved marktiert?

pir187 *verwirrtsei*

----------

## dakjo

Weil ich mein Problem dadurch gesolved haben, das ich erstmal das ebuild maskiert habe.

Danach tut es ja.

Und das jetzt busybox anstatt sash verwendet wird ist ja dann halt ne profile vorgabe.

----------

## TheCurse

Jo, seh ich auch so.

----------

## sokar2000

Ich habs gerade auf meinem Notebook ausprobiert (Alles stable ausser baselayout, da meine WLan-Karte mit dem stablen baselayout net harmonieren wollte) - funzt.

Bin grad am Updaten eines Servers (alles stable), mal sehen obs dort auch will.

----------

## Garwin

Amd64 hier, größtenteils stable, bis auf ein paar Kleinigkeiten:

ebenfalls Abbruch mit obigem Fehler.

----------

## pir187

bin gerade nach hause und habe mal ein 

```
emerge sync
```

 gemacht - ist ohne probs auf meinem x86-sys durchgelaufen. das scheint wohl auch noch an anderen einstellungen zu liegen?!

naja, anscheinend läuft es ja...

schönes we, pir187

----------

## SinoTech

Also bei mir funktionieren beide stable Versionen von busybox nicht. Allerdings nicht der selbe Fehler wie bei euch, sondern beschwert sich über die pthread Library. Evtl. weiß jemand Rat ? Habe sonst nämlich nirgends im Forum was gefunden.

```

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../libc.a(libc-tls.o): warning: common is here

/usr/local/portage_tmp/portage/busybox-1.00-r1/work/busybox-1.00/libpwdgrp/libpwdgrp.a(getgrnam_r.o): warning: Using 'getgrnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

/usr/local/portage_tmp/portage/busybox-1.00-r1/work/busybox-1.00/libpwdgrp/libpwdgrp.a(getpwnam_r.o): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../libc.a(setuid.o)(.text+0x29): In function `setuid':

: undefined reference to `__libc_pthread_functions'

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../libc.a(setgid.o)(.text+0x29): In function `setgid':

: undefined reference to `__libc_pthread_functions'

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../libc.a(seteuid.o)(.text+0x32): In function `seteuid':

: undefined reference to `__libc_pthread_functions'

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../libc.a(setegid.o)(.text+0x32): In function `setegid':

: undefined reference to `__libc_pthread_functions'

collect2: ld returned 1 exit status

distcc[15517] ERROR: compile (null) on localhost failed

make: *** [busybox] Error 1

!!! ERROR: sys-apps/busybox-1.00-r1 failed.

!!! Function src_compile, Line 134, Exitcode 2

!!! (no error message)

!!! If you need support, post the topmost build error, NOT this status message.

```

Habe folgende ausprobiert:

busybox-1.00-r1

busybox-1.00-r4

Jedesmal der gleiche Fehler. Hier mein "emerge --info":

```

$ emerge --info

Gentoo Base System version 1.4.16

Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1,glibc-2.3.4.20040808-r1, 2.6.11-gentoo-r8 i686)

=================================================================

System uname: 2.6.11-gentoo-r8 i686 AMD Athlon(tm) XP 1700+

Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 11 2005, 20:28:37)]

distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]

dev-lang/python:     2.3.4-r1

sys-apps/sandbox:    [Not Present]

sys-devel/autoconf:  2.13, 2.59-r6

sys-devel/automake:  1.8.5-r3, 1.4_p6, 1.5, 1.7.9-r1, 1.6.3, 1.9.5

sys-devel/binutils:  2.15.92.0.2-r7

sys-devel/libtool:   1.5.16

virtual/os-headers:  2.6.8.1-r1, 2.6.8.1-r2

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe -msse -mfpmath=sse"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"

CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"

CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe -msse -mfpmath=sse"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoaddcvs autoconfig ccache distcc distlocks sandbox sfperms strict"

GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo"

MAKEOPTS="-j6"

PKGDIR="/usr/portage/packages"

PORTAGE_TMPDIR="/usr/local/portage_tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage_over"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="x86 3dnow X alsa apache2 arts audiofile avi berkdb bitmap-fonts bonobo cdr crypt cscope cups curl dvd eds emboss encode esd fam flac foomaticdb fortran freetds gdbm gif gimpprint glut gnome gpm gtk gtk2 gtkhtml imagemagick imlib ipv6 java jpeg junit kdeenablefinal kerberos libg++ libwww mad maildir mikmod mmx motif mozilla mp3 mpeg mysql ncurses nls nptl nptlonly nvidia odbc ogg oggvorbis opengl oss pam pdflib perl png ppds python readline samba sdl slang snmp spell sse ssl svga tcltk tcpd tiff truetype truetype-fonts type1-fonts vorbis win32codecs xine xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"

Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

```

Mfg

Sino

----------

## pir187

nur mal so nebenbei:

```
MAKEOPTS="-j6"
```

 --> hast du 5 cpus in deinem rechner  :Shocked:  ?

pir187 *erstaunt*

----------

## dakjo

@SinoTech: Eventuell schon mal revdep-rebuild und emerge world -uD laufen lassen?

----------

## ChrisM87

Hi,

bei mir auch Fehlschlag auf meinem Desktop-PC und auf meinem Server (nur stable).

Sorry, aber dass sich sowas nach stable einschleicht, sollte echt nicht passieren dürfen. Vielleicht wäre es doch sinnvoll, eine weitere "Ebene" einzuführen, Debian hat ja auch drei (stable/testing/unstable).

ChrisM

----------

## SinoTech

 *pir187 wrote:*   

> nur mal so nebenbei:
> 
> ```
> MAKEOPTS="-j6"
> ```
> ...

 

Nope, aber mit Hilfe von DISTCC läuft Kompilierung auf 3 Rechnern. Hab die Formel "2 * ${ANZAHL_RECHNER}" benutzt.

 *dakjo wrote:*   

> 
> 
> @SinoTech: Eventuell schon mal revdep-rebuild und emerge world -uD laufen lassen?
> 
> 

 

Gute Idee. Werd ich gleich mal ausprobieren .. wieso bin ich da eigentlich nicht drauf gekommen  :Wink:  ?

Mfg

Sino

----------

## SinoTech

Hat leider nichts geholfen ... immer noch der gleiche Fehler  :Sad: .

Mfg

Sino

----------

## pir187

@SinoTech:

```
Nope, aber mit Hilfe von DISTCC läuft Kompilierung auf 3 Rechnern. Hab die Formel "2 * ${ANZAHL_RECHNER}" benutzt.
```

ach so, das ist natürlich praktisch  :Twisted Evil:  ... dann hab ich nichts gesagt. hätte ja sein können, daß es etwas mit dem fehler zu tun hat.

pir187

----------

## dakjo

So nachdem da jemand im ebuild direkt was geaendert hat funktioniert es jetzt hier.

Also syncen und nochmal neu probieren.

----------

## SinoTech

 *pir187 wrote:*   

> @SinoTech:
> 
> ```
> Nope, aber mit Hilfe von DISTCC läuft Kompilierung auf 3 Rechnern. Hab die Formel "2 * ${ANZAHL_RECHNER}" benutzt.
> ```
> ...

 

Jo, habe zum testen mal DISTCC rausgenommen und MAKEOPTS auf "-j2" gestellt. Hat aber leider nichts geholfen. Naja, werd mal neu syncen und dann nochmal testen .. aber erst morgen, jetzt will ich ins Bett  :Smile: .

Mfg

Sino

----------

## Genone

 *dakjo wrote:*   

> Ebuilds vorher mal auf x86 Maschinen zu testen. Wie ich festgestellt habe funktioniert es auf ~x86 Maschinen.

 

Wenn das Problem mal so einfach wäre. Momentan siehts so aus, als ob sich das Problem auf USE=nptlonly zurückführen lässt.

----------

## deejay

bei mir ist es auch ohne probleme durchgelaufen ... Benutze ein stable System (x86).

Keine Probleme, keine Fehler, alles wunderbar  :Wink: 

gruß

dee

----------

## SinoTech

Tja, bei mir leider nicht. Habe auch ein x86 System (Bis auf ein paar Ausnahmen wie "nvu", "mldonkey", ... aber sollte damit nichts zu tun haben). Naja, wie auch immer, habs jetzt einfach mal maskiert. Hatte es vorher nicht gebraucht und werde es wohl auch in näherer Zukunft nicht brauchen.

Mfg

Sino

----------

## moe

Bei mir isses auch auf 2 Rechnern durchgelaufen, Mischsystem (überwiegend x86) mit nptl aber nicht nptlonly..

----------

## klemi

zur make.conf von SiniTech:

So weit ich weiß sollte man die Zeile "SYNC" entfernen - sie wird nicht mehr benötigt, wie in einem anderen Thread zu lesen war!

----------

## SinoTech

 *klemi wrote:*   

> zur make.conf von SiniTech:
> 
> So weit ich weiß sollte man die Zeile "SYNC" entfernen - sie wird nicht mehr benötigt, wie in einem anderen Thread zu lesen war!

 

Ist in meiner "make.conf" auch eigentlich gar nicht enthalten.

Mfg

Sino

----------

## dakjo

Ja, scheint so das es an nptlonly liegt. Zumindest liess es sich jetzt auf den rechnern ohne nptlonly compilieren.

----------

## psyqil

Hm. Hier geht's auch mit ntplonly...

----------

## dakjo

Ok, der Bug scheint gefixt zu sein! Nachdem workaround, der jetzt im tree ist funktioniert es hier auf allen nptlonly boxen.

BUG 94879

----------

## TheCurse

Right, bei mir auch!

----------

## aZZe

 *Genone wrote:*   

>  *dakjo wrote:*   Genau das macht so den sinn.... ich kann doch sowas nicht umstellen und dann dabei so brOken shit verwenden.
> 
> So wird Gentoo nie gross. 
> 
> Konkrete Verbesserungsvorschläge?

 

Ich kann mich dakjo da nur anschließen! Es wird anscheinend sehr schlampig bei Gentoo in der letzten Zeit getestet und einfach nur noch stable gemarked und sowas ist im warsten Sinne des Wortes "shit". Mehr Verbesserungsvorschläge kann man wohl nicht bringen. Das Zauberwort heißt "TESTEN".

----------

## Mr_Maniac

Ich mache hingegen manchmal genau die gegenteilige Beobachtung:

Manche Sachen, die perfekt stabil laufen sind immernoch masked...

Aber andererseits... Sollten nicht die USER mittesten?

Kann man nicht irgendwie Erfahrungsberichte einsenden oder sogar über Pakete berichten, die man im Portage vermisst?

(z.B. Armagetron Advanced, nexuiz [na gut, das ist ja auch ziemlich neu]...)

----------

## beejay

 *aZZe wrote:*   

>  *Genone wrote:*    *dakjo wrote:*   Genau das macht so den sinn.... ich kann doch sowas nicht umstellen und dann dabei so brOken shit verwenden.
> 
> So wird Gentoo nie gross. 
> 
> Konkrete Verbesserungsvorschläge? 
> ...

 

Du bist gerne dazu eingeladen, ein ~x86-System zu fahren und Feedback zu erteilen.

Ach halt - das hatten wir ja schon mehrere Male: Selber beteiligen ist immer schlecht; ein paar Meter Abstand halten und über den Zaun nörgeln kommt immer besser.

----------

## schachti

 *Mr_Maniac wrote:*   

> 
> 
> Kann man nicht irgendwie Erfahrungsberichte einsenden oder sogar über Pakete berichten, die man im Portage vermisst?
> 
> 

 

Dafür ist doch bugs.gentoo.org gedacht, wenn ich Dich recht verstehe...

----------

## aZZe

 *beejay wrote:*   

> 
> 
> Du bist gerne dazu eingeladen, ein ~x86-System zu fahren und Feedback zu erteilen.
> 
> Ach halt - das hatten wir ja schon mehrere Male: Selber beteiligen ist immer schlecht; ein paar Meter Abstand halten und über den Zaun nörgeln kommt immer besser.

 

Ich dachte so ein Kommentar würde gar nicht mehr kommen. Aber der Mensch scheint verlässlicherweise ein Gewohnheitstier zu sein  :Cool:   Ich weiß nicht was das jedesmal soll, dass sich devs jedesmal auf den Schlips getreten fühlen, wenn was nicht funktioniert und es dann immer heißt mach es doch besser. Irgendwie erinnert mich das Geknatsche an die Vorschulgruppe meiner Nichte.  Es soll sich dabei keiner persönlich angegriffen fühlen, aber man muss doch auch sehen, dass solche Aktionen mindestens in den letzten 6 Monaten sehr häufig vorkamen und da fragt man nicht zurecht nach dem WARUM?

----------

## beejay

 *aZZe wrote:*   

>  *beejay wrote:*   
> 
> Du bist gerne dazu eingeladen, ein ~x86-System zu fahren und Feedback zu erteilen.
> 
> Ach halt - das hatten wir ja schon mehrere Male: Selber beteiligen ist immer schlecht; ein paar Meter Abstand halten und über den Zaun nörgeln kommt immer besser. 
> ...

 

Es kommt vielleicht auch darauf an, wer solche Kommentare abgibt. Wer nur benutzt - und das mit einer gottgegeben Selbstverständlichkeit - der kann immer einfach kritisieren.

----------

## aZZe

Anscheinend wurde der wunde Punkt ja getroffen und das von denen, die das Sysetm eh nur anwenden. Aber Schluss damit das führt eh zu nichts.

----------

## Genone

 *aZZe wrote:*   

>  *Genone wrote:*    *dakjo wrote:*   Genau das macht so den sinn.... ich kann doch sowas nicht umstellen und dann dabei so brOken shit verwenden.
> 
> So wird Gentoo nie gross. 
> 
> Konkrete Verbesserungsvorschläge? 
> ...

 

Das Problem ist: WAS genau testen? Eine vollständige Testüberdeckung über alle Konfigurationen ist völlig unmöglich (das ist wohl jedem klar), allein schon sämtliche USE Flags eines einzelnen Pakets zu testen ist nicht immer möglich (besonders wenn man mehrere Architekturen testen will), und in diesem Fall war es offenbar sogar ein verstecktes Problem mit einer speziellen Konfiguration der Toolchain (bestimmte glibc Version mit USE=nptlonly).

Das Schlüsselwort in meinem vorherigen Post war "konkret".

----------

## aZZe

 *Genone wrote:*   

> 
> 
> Das Problem ist: WAS genau testen? Eine vollständige Testüberdeckung über alle Konfigurationen ist völlig unmöglich (das ist wohl jedem klar), allein schon sämtliche USE Flags eines einzelnen Pakets zu testen ist nicht immer möglich (besonders wenn man mehrere Architekturen testen will), und in diesem Fall war es offenbar sogar ein verstecktes Problem mit einer speziellen Konfiguration der Toolchain (bestimmte glibc Version mit USE=nptlonly).
> 
> Das Schlüsselwort in meinem vorherigen Post war "konkret".

 

Es ist mir vollkommen klar, dass man einen "Volltest" nicht durchführen kann. Irgendwo ist man seiner Möglichkeiten ja auch beschränkt ist doch vollkommen klar. Aber es so schnell stable zu marken, um abzuwarten ob's hinhaut kann doch auch nicht der richtige Weg sein oder sehe ich das falsch?

----------

## STiGMaTa_ch

 *aZZe wrote:*   

> Aber es so schnell stable zu marken, um abzuwarten ob's hinhaut kann doch auch nicht der richtige Weg sein oder sehe ich das falsch?

 

Da du ja anscheinend so genau bescheid weisst und auch die Beweggründe für das voreilige stable setzen kennst. Und da du ja anscheinend auch weisst, wie man das besser machen kann, warum verfasst du dann nicht mal eine Richtlinie für Zukünftiges Package Handling?  Oder warum setzt du dich nicht hin, und beschreibst wie Package Developer solche Fehler in Zukünft vermeiden können?

Falls du des Englischen nicht mächtig bist, keine bange, ich werd dir gerne versuchen zu helfen und den Text ins Englische zu übersetzen. Gemeinsam können wir diesen dann dem Englisch sprechenden Developer Grüppchen vortragen. Damit könnte das Problem zumindest minimiert werden...

Aber das ist dann doch ganz was anderes als mit dem Finger auf andere zu zeigen, Nicht? Da musst du ja direkt selber denken und was beitragen...

 *aZZe wrote:*   

> Jedem das Seine, mir das Meiste...

 

Aha...ja, alles klar  :Rolling Eyes: 

Gruss

STiGMaTa

----------

## beejay

 *STiGMaTa_ch wrote:*   

>  *aZZe wrote:*   Aber es so schnell stable zu marken, um abzuwarten ob's hinhaut kann doch auch nicht der richtige Weg sein oder sehe ich das falsch? 
> 
> Da du ja anscheinend so genau bescheid weisst und auch die Beweggründe für das voreilige stable setzen kennst. Und da du ja anscheinend auch weisst, wie man das besser machen kann, warum verfasst du dann nicht mal eine Richtlinie für Zukünftiges Package Handling?  Oder warum setzt du dich nicht hin, und beschreibst wie Package Developer solche Fehler in Zukünft vermeiden können?
> 
> Falls du des Englischen nicht mächtig bist, keine bange, ich werd dir gerne versuchen zu helfen und den Text ins Englische zu übersetzen. Gemeinsam können wir diesen dann dem Englisch sprechenden Developer Grüppchen vortragen. Damit könnte das Problem zumindest minimiert werden...
> ...

 

Lass es - jetzt kommt gleich das Argument "Bringt ja sowieso nichts, hört ja keiner zu"

----------

## MatzeOne

 *Quote:*   

> >>> Regenerating /etc/ld.so.cache...
> 
> >>> sys-apps/busybox-1.00-r4 merged.
> 
> 

 

Klappt doch.

An dieser Stelle ein dickes Lob an die Gentoo Developer und Open Source Progger allgemein.

----------

## hoschi

 *aZZe wrote:*   

>  *Genone wrote:*   
> 
> Das Problem ist: WAS genau testen? Eine vollständige Testüberdeckung über alle Konfigurationen ist völlig unmöglich (das ist wohl jedem klar), allein schon sämtliche USE Flags eines einzelnen Pakets zu testen ist nicht immer möglich (besonders wenn man mehrere Architekturen testen will), und in diesem Fall war es offenbar sogar ein verstecktes Problem mit einer speziellen Konfiguration der Toolchain (bestimmte glibc Version mit USE=nptlonly).
> 
> Das Schlüsselwort in meinem vorherigen Post war "konkret". 
> ...

 

Einwurf: NPTLONLY kann man wohl langsam als quasi Standard sehen.

Stellt sich mir die Frage, warum NPTL nicht schon längst Systemstandard ist?

----------

## dakjo

Um das ganze hier mal etwas sachlicher zu betrachten, wegen der qa und was mann besser machen könnte.

Die Frage die sich mir hierbei stellt, ist nicht unbedingt die des testens, sondern die wie solche "System" veränderungen eingebracht werden.

busybox-1.00-r1 ist seit dem 11 Dec 2004 stabel auf x86.

An einem tag wird dann aber das System verändert (sash wird durch busybox ersetzt) und gleichzeitig eine _neu_ ungetestete Version von busybox stable.

Die Frage ist, hätte mann es nicht erst mit busybox-1.00-r1 machen sollen? Oder zumindest busybox-1.00-r4 mal so 2-3 Wochen quasi _in_the_wild_ testen sollen. Wären dann keine Bugs dazu mehr eingetroffen, haette mann es dann erst umstellen sollen.

Ich will jetzt nicht mehr meckern, es soll eine konstruktive Kritik sein. Bzw, vielleicht ein denkanstoss.

Ups, ich muss doch noch meckern. Changlog einträge wären echt nicht schlecht. Hierdran würden sich nämlich auch für die nicht so in der Materie steckenden leute evtl. einiges an klarheit ergeben. Z.B. auch das das ebuild inerhalb einer version sich jetzt 8 mal geändert hat.

Siehe Gentoo CVS dazu.

Der einzigste Changlog eintrag besteht aber nur aus:

 *Quote:*   

> 
> 
>   03 Jun 2005; <solar@gentoo.org> busybox-1.00-r4.ebuild:
> 
>   - remove redirection of stderr to null when static linking. This will make the
> ...

 

--Edit--

Und @beejay bitte mach mir nicht auch den vorwurf das ich selber nicht tu und nur mecker.

Ich werde die developer demnächst ja aktiv unterstützen. Denn nur wer was tut kann auch was bewegen.

MfG

----------

## amne

Tun wir uns dann bitte nicht gegenseitig beschimpfen tun und gemeine Sachen sagen, ok?

----------

## beejay

 *dakjo wrote:*   

> 
> 
> Und @beejay bitte mach mir nicht auch den vorwurf das ich selber nicht tu und nur mecker.
> 
> Ich werde die developer demnächst ja aktiv unterstützen. Denn nur wer was tut kann auch was bewegen.
> ...

 

Gegen Dich habe ich nicht gesprochen - sorry, wenn das so aussah. Du hast Gentoo erwiesenermassen unterstützt und tust es noch.

Es geht mir nur um das allgemeine gebashe, dass immer wieder gerne losgelassen wird. Und wenn man Leute darauf anspricht ist es wie mit der Lokalpolitik: "Na dann werde doch aktiv und ändere was" - "Ich!? Ne, ich nicht!"

----------

## Genone

 *hoschi wrote:*   

>  *aZZe wrote:*   
> 
> Es ist mir vollkommen klar, dass man einen "Volltest" nicht durchführen kann. Irgendwo ist man seiner Möglichkeiten ja auch beschränkt ist doch vollkommen klar. Aber es so schnell stable zu marken, um abzuwarten ob's hinhaut kann doch auch nicht der richtige Weg sein oder sehe ich das falsch? 
> 
> Einwurf: NPTLONLY kann man wohl langsam als quasi Standard sehen.
> ...

 

Naja, jetzt könnte man diesen Fall genau als Beispiel anführen  :Twisted Evil: 

----------

