# [info] openssl-0.9.8

## .:chrome:.

è stato stabilizzato openssl-0.9.8

molte cose sono cambiate rispetto alla 0.9.7, quindi è fondamentale che si faccia un revdep-rebuild dopo l'aggiornamento

 *Quote:*   

>  * You must re-compile all packages that are linked against
> 
>  * OpenSSL 0.9.7 by using revdep-rebuild from gentoolkit:
> 
>  * # revdep-rebuild --library libssl.so.0.9.7
> ...

 Last edited by .:chrome:. on Wed Sep 06, 2006 5:12 pm; edited 1 time in total

----------

## ProT-0-TypE

grassie, non ci avevo fatto caso!

----------

## cloc3

 *k.gothmog wrote:*   

> quindi è fondamentale che si faccia un revdep-rebuild dopo l'aggiornamento
> 
> 

 

grazie.

avevo letto la tua prima versione del post, che non riportava così chiaramente l'output di emerge.

allora ho provato un semplice revdep-rebuild e ho scoperto con sorpresa che non ricompilava praticamente nulla (anche ripensando all'ultimo aggiornamento di openssl).

poi ho un po' indagato sul fenomeno, ho scoperto l'output di emerge e ho scoperto che nel mio sistema (accanto a quelle nuove) esistono ancora le vecchie versioni della libreria /usr/lib/libssl.so.0.9.7, che non sono state ripulite da emerge (cosa probabilmente voluta dagli sviluppatori di gentoo).

Allora mi chiedo se ricompilare tutto quanto sia veramente indispensabile  se non sia possibile lasciare lavorare i pacchetti con le vecchie librerie fino a  naturale aggiornamento o se questo determini problemi gravi di sicurezza o di stabilità.

----------

## .:chrome:.

ehm, si... grave dimenticanza

scusami  :Smile: 

----------

## cloc3

 *k.gothmog wrote:*   

> ehm, si... grave dimenticanza
> 
> scusami 

 

 :Smile:   :Smile:   :Smile: 

ehm, si ... è indispensabile ricompilare  :Question: 

oppure

ehm, si ... puoi usare le vecchie librerie  :Question: 

poi, se lo desideri, ci spieghi qualche differenza.

----------

## .:deadhead:.

io ipotizzo... Se la libreria l'hanno aggiornata sarà perchè c'erano bug o altre amenità . Il fatto che la libreria vecchia venga lasciata forse è dovuto al fatto che non volevaono poi vedersi i bugreports pieni di "ho aggiornato openssl ora non va + una cippa!"

----------

## .:chrome:.

è indispensabile compilare.

è cambiata l'implementazione delle funzioni, e sono cambiate le funzioni implementate.

il nuovo ebuild non cancella i due files critici, altrimenti avresti un transitorio in cui non funziona più niente (e dico NIENTE) ma ti dice chiaramente di lanciare revdep-rebuild e poi cancellartelo a mano

lasciare i vecchi files può anche funzionare, ma al prima ggiornamento ti trovi roba compilata contro 0.9.7 e quello che hai appena aggiornato che è stato compilato contro 0.9.8 (ammesso e non concesso che questo aggiornamento vada a buon fine perché ho i miei dubbi anche su questo), e le due versioni NON SONO COMPATIBILI TRA DI LORO

per la cronaca, la nuova versione non corregge bug, ma corregge l'implementazione (penosa) della vecchia versione, migliora le vecchie primitive crittografiche, irrobustendo quelle che sono ormai broken. Fa uso maggiore di meccanismi crittografici relativamente nuovi, che sono diventati accessibili con l'aumentare delle risorse di calcolo (come la crittografia basata su logaritmi discreti).

So poi che nella versione 0.9.8 è stat itrodotta la crittografia ECC (Ellyptic-Curve Cryptography) ma non so se l'ebuild la implementi ed in questo momento mi sento troppo pigro per andare a curiosarci dentro  :Wink:  personalmente dubito, perché solo quattro mesi fa con ECC non funzionava più una mazza

----------

## Ic3M4n

in pratica mi vuole ricompilare mezzo mondo.   :Rolling Eyes: 

che due pelotas, dopo il mondo per l'upgrade di gcc (che ho fatto su un solo pc) per chi l'ha già fatto è un bel macello perchè vuol dire ricompilare ancora un macello di roba. per fortuna che ho ccache abilitata, magari qualcosa risparmio.

----------

## tizio

```

* You must re-compile all packages that are linked against

* OpenSSL 0.9.7 by using revdep-rebuild from gentoolkit:

* # revdep-rebuild --library libssl.so.0.9.7

* # revdep-rebuild --library libcrypto.so.0.9.7

* After this, you can delete /usr/lib/libssl.so.0.9.7

* and /usr/lib/libcrypto.so.0.9.7

```

perdonatemi se dico una baggianata... ma è indispensabile lanciare due volte il revdep-rebuild su due librerie diverse?

in questo modo i programi che le usano entrambe non vengono compilati due volte?

non c'è un modo per fixare entrambe le librerie in un colpo solo?

EDIT:

ok era una baggianata... quando vengono ricompilati alla prima useranno le nuove librerie quindi non entreranno nel secondo revdep-rebuild

scusate ancora...sarà l'orario...   :Razz: 

----------

## lavish

Ho messo in evidenza il thread  :Wink: 

----------

## cloc3

grazie k.gothmog .

 :Cool:  avete visto che lo abbiamo stanato?

@tizio : gli insiemi di ebuild relativi alle due librerie sono pressoché sovrapposti.

dopo il primo revdep, il secondo troverà ben poco lavoro da completare.

----------

## Guglie

azz, volevo fare l'aggiornamento con calma nel week-end, ma oggi con un --depclean fatto senza controllare bene mi ha disinstallato openssl, togliendo pure le librerie   :Rolling Eyes: 

al momento non ho altre macchine con gentoo installata a disposizione: non è che un'anima volonterosa potrebbe uploadarmi da qualche parte libssl.so.0.9.7 e libcrypto.so.0.9.7?

----------

## .:chrome:.

 *cloc3 wrote:*   

> avete visto che lo abbiamo stanato?

 

stanato? a cosa ti riferisci?

----------

## cloc3

 *k.gothmog wrote:*   

> 
> 
> stanato? a cosa ti riferisci?

 

a nulla, che ci hai detto quattro cose in più  :Smile: 

----------

## Ic3M4n

non basta quella faccina...

----------

## makoomba

alcuni sw non compilano con la nuova versione (es: imapproxy).

bah, io rimando per il momento

non mi pare ci siano falle di sicurezza tali da costringere all'upgrade immediato.

----------

## tizio

è normale che facendo:

revdep-rebuild --library libcrypto.so.0.9.7

trovi  /usr/lib/libssl.so.0.9.7 e mi continui a riemergere openssl stesso?

la versione 0.9.8c non dovrebbe sostituire proprio questa libreria?

dove sbaglio?

----------

## cloc3

 *tizio wrote:*   

> è normale che facendo:
> 
> revdep-rebuild --library libcrypto.so.0.9.7
> 
> trovi  /usr/lib/libssl.so.0.9.7 e mi continui a riemergere openssl stesso?
> ...

 

si:

```

linux99 ~ # ldd /usr/lib/libssl.so.0.9.7

        ...

        libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb7e26000)

        ...

```

----------

## Sephirot

dopo aver dato  # revdep-rebuild --library libssl.so.0.9.7 , mentre ri-emergeva  app-crypt/qca-tls-1.0-r2 mi da' questo errore:

```
 * Applying qca-pathfix.patch ...                                         [ ok ]

>>> Source unpacked.

>>> Compiling source in /var/tmp/portage/qca-tls-1.0-r2/work/qca-tls-1.0 ...

Configuring qca-tls ...

Verifying Qt 3.x Multithreaded (MT) build environment ... ok

Checking for OpenSSL ... yes

Good, your configure finished. Now run 'make'.

i686-pc-linux-gnu-g++ -c -pipe -Wall -W -march=pentium-m -O2 -pipe -fno-strict-aliasing -D_REENTRANT -fPIC  -DQCA_PLUGIN -DOSSL_097 -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_PLUGIN -DQT_SHARED -DQT_TABLET_SUPPORT -march=pentium-m -O2 -fomit-frame-pointer -pipe -mfpmath=sse -mmmx -msse -msse2 -fforce-addr  -fprefetch-loop-arrays -I/usr/qt/3/mkspecs/linux-g++ -I/var/tmp/portage/qca-tls-1.0-r2/work/qca-tls-1.0 -I/usr/qt/3/include -o qca-tls.o qca-tls.cpp

qca-tls.cpp: In member function 'virtual bool RSAKeyContext::createFromDER(const char*, unsigned int)':

qca-tls.cpp:457: error: invalid conversion from 'unsigned char**' to 'const unsigned char**'

qca-tls.cpp:457: error:   initializing argument 2 of 'RSA* d2i_RSA_PUBKEY(RSA**, const unsigned char**, long int)'

qca-tls.cpp: In member function 'virtual bool CertContext::createFromDER(const char*, unsigned int)':

qca-tls.cpp:802: error: invalid conversion from 'unsigned char**' to 'const unsigned char**'

qca-tls.cpp:802: error:   initializing argument 2 of 'X509* d2i_X509(X509**, const unsigned char**, long int)'

make: *** [qca-tls.o] Error 1

!!! ERROR: app-crypt/qca-tls-1.0-r2 failed.

Call stack:

  ebuild.sh, line 1539:   Called dyn_compile

  ebuild.sh, line 939:   Called src_compile

  qca-tls-1.0-r2.ebuild, line 32:   Called die

!!! emake failed

!!! If you need support, post the topmost build error, and the call stack if relevant.

revdep-rebuild failed to emerge all packages

you have the following choices:

- if emerge failed during the build, fix the problems and re-run revdep-rebuild

    or

- use -X or --package-names as first argument (trys to rebuild package, not exact

  ebuild)

    or

- set ACCEPT_KEYWORDS="~<your platform>" and/or /etc/portage/package.unmask

  (and remove /root/.revdep-rebuild_eef3b244.5_order to be evaluated again)

    or

- modify the above emerge command and run it manually

    or

- compile or unmerge unsatisfied packages manually, remove temporary files and

  try again (you can edit package/ebuild list first)

To remove temporary files, please run:

rm /root/.revdep-rebuild*.?_*

```

bha.... ora pero' sono troppo stanco per sbatterci la testa sopra.

----------

## tizio

 *Sephirot wrote:*   

> dopo aver dato  # revdep-rebuild --library libssl.so.0.9.7 , mentre ri-emergeva  app-crypt/qca-tls-1.0-r2 mi da' questo errore:
> 
> 

 

metti qca-tls in package.keywords e installa la r3, a me ha funzionato

----------

## Sephirot

Fatto ma il problema si ripresenta (stesso errore). revdep-rebuild ricompila la r2.

----------

## .:chrome:.

 *Sephirot wrote:*   

> Fatto ma il problema si ripresenta (stesso errore). revdep-rebuild ricompila la r2.

 

c'è un altro con lo stesso problema... installa A MANO la r3 e non lasciar fare a revdep-rebuild quello che vuole

----------

## .:chrome:.

ho notato che la versione 2.1.21-r2 di cyrus-sasl non funziona più con questo pacchetto.

la 2.1.22 invece compila regolarmente.

----------

## bandreabis

 *k.gothmog wrote:*   

> è stato stabilizzato openssl-0.9.8
> 
> molte cose sono cambiate rispetto alla 0.9.7, quindi è fondamentale che si faccia un revdep-rebuild dopo l'aggiornamento
> 
>  *Quote:*    * You must re-compile all packages that are linked against
> ...

 

Ed io che sono su AMD64?

 *Quote:*   

>  * You must re-compile all packages that are linked against
> 
>  * OpenSSL 0.9.7 by using revdep-rebuild from gentoolkit:
> 
>  * # revdep-rebuild --library libssl.so.0.9.7
> ...

 

 :Exclamation: 

----------

## .:chrome:.

non credo che quelle librerie debbano essere portate a 64 bit.

o forse si?

a naso mi verrebbe da dire di no

----------

## bandreabis

 *k.gothmog wrote:*   

> non credo che quelle librerie debbano essere portate a 64 bit.
> 
> o forse si?
> 
> a naso mi verrebbe da dire di no

 

Non capisco la domanda.

Cmq così disse l'emerge di openssl-0.9.8.

----------

## .:chrome:.

 *bandreabis wrote:*   

> Cmq così disse l'emerge di openssl-0.9.8.

 

ah beh... allora niente. ho sbagliato

fai finta che non abbia scritto nulla  :Smile: 

----------

## cloc3

 *bandreabis wrote:*   

> Ed io che sono su AMD64? 
> 
> 

 

forse una differenza c'è.

alla fine, potresti aver bisogno di cancellare anche le librerie in emulazione /emul/linux/x86/usr/lib/libssl.so.0.9.7

----------

## bandreabis

 *cloc3 wrote:*   

>  *bandreabis wrote:*   Ed io che sono su AMD64? 
> 
>  
> 
> forse una differenza c'è.
> ...

 

Infatti l'avevo visto quel file, ora ho anche verificato che ci fosse anche /emul/linux/x86/usr/lib/libssl.so.0.9.8 quindi credo che tu abbia ragione.

Grazie.

Andrea

----------

## Sephirot

 *k.gothmog wrote:*   

>  *Sephirot wrote:*   Fatto ma il problema si ripresenta (stesso errore). revdep-rebuild ricompila la r2. 
> 
> c'è un altro con lo stesso problema... installa A MANO la r3 e non lasciar fare a revdep-rebuild quello che vuole

 

cmq si e' risolto da se', forse bastava riavviare pero' mi sembra un po' strana come spiegazione.

----------

## .:chrome:.

 *Sephirot wrote:*   

> cmq si e' risolto da se', forse bastava riavviare pero' mi sembra un po' strana come spiegazione.

 

decisamente. Linux è un sistema operativo decente. non è windows

avrai fatto nel mentre alcuni aggiornamenti che hanno sistemato la cosa

----------

## richard77

Io non ho openssl in world. Mi conviene upgradarlo con "emerge --1 openssl" e poi usare revdep-rebuild oppure aspettare che l'aggiornamento avvenga "naturalmente"?

[EDIT emerge --1 world -> emerge --1 openssl)

----------

## .:chrome:.

ovviamente non hai openssl in world. non è un pacchetto che viene installato dall'utente, ma come dipendenza di altri

world non dovrebbe mai contenere pacchetti della categoria dev-libs

ma non capisco perché ti poni il problema

comuqnue basta (leggere la man di portage) emerge -u openssl: l'aggiornamento di un pacchetto già installato non tocca world

----------

## richard77

Nella fretta mi sono espresso male.

E' giusto che openssl non sia in world.

Comunque la mia domanda è se conviene aggiornare il prima possibile per minimizzare il numero di pacchetti da ricompilare o aspettare che tutti i pacchetti siano stati aggiornati per la compilazione con la nuova versione (visto anche che:

 *makoomba wrote:*   

> alcuni sw non compilano con la nuova versione (es: imapproxy).
> 
> bah, io rimando per il momento non mi pare ci siano falle di sicurezza tali da costringere all'upgrade immediato.

 

----------

## .:chrome:.

 *richard77 wrote:*   

> Comunque la mia domanda è se conviene aggiornare il prima possibile per minimizzare il numero di pacchetti da ricompilare o aspettare che tutti i pacchetti siano stati aggiornati per la compilazione con la nuova versione

 

come ha giustamente detto makoomba, proprio perché alcuni VECCHI pacchetti non compilano con la nuova versione conviene prima fare un aggiornamento globale e poi fare tutte le procedure per aggiornare openssl

----------

## syntaxerrormmm

Non so se è attinente, ma posto qui; nel caso non lo sia, prego un Mod di separare il post, magari con titolo 'ssh Segmentation Fault'

Dunque, dalle poche parole che ho detto, credo sia chiaro il problema; ho postato qui perché sospetto il problema sia di openssl. Un paio di info aggiuntive:

```
# equery l -i openssl

 * installed packages

dev-libs/openssl-0.9.8c

# equery l -i openssh

 * installed packages

net-misc/openssh-4.3_p2-r2
```

E poi...

```
# ssh -p 25666 localhost

ssh_exchange_identification: Connection closed by remote host
```

Quale "remote"? -_-

```
# ldd `which ssh`

   linux-gate.so.1 =>  (0xffffe000)

   libresolv.so.2 => /lib/libresolv.so.2 (0xb7f0a000)

   libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb7da4000)

   libutil.so.1 => /lib/libutil.so.1 (0xb7da0000)

   libz.so.1 => /lib/libz.so.1 (0x41a13000)

   libnsl.so.1 => /lib/libnsl.so.1 (0xb7d8b000)

   libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7d5d000)

   libc.so.6 => /lib/libc.so.6 (0xb7c40000)

   libdl.so.2 => /lib/libdl.so.2 (0xb7c3c000)

   /lib/ld-linux.so.2 (0xb7f3b000)
```

Any ideas? Grazie.

----------

## .:chrome:.

hai compilato openssl con la USE sse2?

----------

## gutter

 *syntaxerrormmm wrote:*   

> Non so se è attinente, ma posto qui;

 

Il posto è quello giusto   :Laughing: 

Basta semplicemente che tu ricompili openssh.

P.S.: Leggiti il primo post del thread e segui le istruzioni che si trovano alla fine dell'ebuild di openssl.

----------

## Luca89

 *k.gothmog wrote:*   

> hai compilato openssl con la USE sse2?

 

Io ho lo stesso problema e ho compilato openssl con la use sse2, che problemi comporta (oltre a questo di openssh)?

EDIT: per ora pare sia un problema solo per openssh, bug

----------

## .:chrome:.

 *Luca89 wrote:*   

> Io ho lo stesso problema e ho compilato openssl con la use sse2, che problemi comporta (oltre a questo di openssh)?

 

non riesco a capirlo. so che io ho dovuto ricompilare openSSH, che non accettava più nessuna connessione, da quando ho compilato openSSL con USE="sse2"

ragiovevolmente non dovrebbe essere influente, perché il protocollo delle funzioni di openSSL non dovrebbe affatto cambiare.

eppure è stato l'unico cambiamento che ho fatto al sistema, e subito dopo ho provato openSSH e me lo sono trovato così

[OT] a me 'ste openSSL iniziano a stancare. tra un po' passo a GnuTLS

----------

## Luca89

Ho risolto utilizzando in entrambe le macchine (client e server) openssh-4.3_p2-r2

----------

## .:chrome:.

 *Luca89 wrote:*   

> Ho risolto utilizzando in entrambe le macchine (client e server) openssh-4.3_p2-r2

 

a me è bastato ricompilare il server. quello che mi chiedo è cosa succederà (se e) quando farò l'aggiornamento sulle macchine in produzione.

se mi si blocca l'accesso a SSH che faccio?

comuque ora sto provado i programmi che usano openSSL. sembra che openSSH sia l'unico prendersela

----------

## .:chrome:.

notizie dal fronte:

a quanto pare la USE sse2 introdotta con la versione 0.9.8c del pacchetto era fonte di qualche grosso tipo di incompatibilità, ma sono sono riuscito a capire esattamente di cosa si trattasse.

è stata rilasciata una revisione del pacchetto che disabilita la USE in questione.

[ebuild     U ]    dev-libs/openssl-0.9.8c-r1 [0.9.8c] USE="zlib -bindist -emacs -test (-sse2%*)"

per chi avesse ricompilato openSSH dopo l'aggiornamento a openSSL-0.9.8c suggerisco di ricompilare ancora una volta

----------

## lavish

mail-mta/nbsmtp non compila

// EDIT: su bugzilla è stato postato il fix  :Wink: 

// EDIT2: fixed in portage  :Smile: 

----------

## Peach

io ho appena scoperto di avere problemi con la ricompilazione di net-firewall/ipsec-tools-0.6.2-r1 come riportato anche in questo post qui

per ora posso anche farne a meno... però...

----------

## otaku

 *Sephirot wrote:*   

> Fatto ma il problema si ripresenta (stesso errore). revdep-rebuild ricompila la r2.

 

da man revdep-rebuild:

```
-X | --package-names

emerge the best packages available, not neccessarily  the  exact

version of the installed package
```

  :Wink: 

----------

## Sephirot

otaku avevo risolto, cmq grazie  :Smile: 

----------

## .:chrome:.

come se non bastasse il casino introdotto dalla 0.9.8 hanno pure voluto fare la versione ottimizzata, che data tutti quei problemi di cui si è parlato con i pacchetti che ne facevano uso.

pare che il problema sia stato risolto. no comment sul COME:

 *l'ultimo ebuild wrote:*   

>  * Due to the way openssl is architected, you cannot
> 
>  * switch between optimized versions without breaking
> 
>  * ABI.  The default i686 0.9.8 ABI was an unoptimized
> ...

 

che palle!

ribelliamoci! passiamo a GnuTLS  :Laughing: 

----------

## dark_knight

 *Quote:*   

> Changes:
> 
> *openssl-0.9.8c-r2 (18 Sep 2006)
> 
>   18 Sep 2006; Mike Frysinger <vapier@gentoo.org> files/gentoo.config-0.9.8,
> ...

 

Quoto l'ultima frase <_<

Senza offesa  :Smile: 

----------

## riverdragon

Hanno fatto bene a rimettere fuori una versione ottimizzata, ho fatto una prova di login ssh su una macchina della mia lan e il risultato si vede ad occhio nudo, da 2 secondi scarsi per la -r1 ad una frazione di secondo per la -r2; chissà come sarebbe stato il passaggio via scp.

----------

## .:chrome:.

ho un fastidioso problema con questa libreria

l'installazione di openldap continua ad essere linkata alle vecchie versioni libssl.so.0.9.7 e libcrypto.so.0.9.7

ho ricompilato diverse volte. ho rimosso i due files in questione. ho ricompilato ancora

non cambia nulla: liblber-2.2.so.7, libldap-2.2.so.7 e libldap_r-2.2.so.7 continuano a essere linkati contro libssl.so.0.9.7 e libcrypto.so.0.9.7, e non mi so spiegare il motivo.

qualcuno ha idea di come potrei risolvere?

----------

## dark_knight

Provato così?

```
You must re-compile all packages that are linked against

OpenSSL 0.9.7 by using revdep-rebuild from gentoolkit:

# revdep-rebuild --library libssl.so.0.9.7

# revdep-rebuild --library libcrypto.so.0.9.7

After this, you can delete /usr/lib/libssl.so.0.9.7

and /usr/lib/libcrypto.so.0.9.7
```

----------

## .:chrome:.

 *dark_knight wrote:*   

> Provato così?
> 
> ```
> You must re-compile all packages that are linked against
> 
> ...

 

ehm... il thread l'ho aperto io, con quel consiglio... era ovvio che l'avessi già fatto  :Wink: 

----------

## dark_knight

/me si cosparge il capo di cenere  :Smile: 

----------

## devilheart

 *k.gothmog wrote:*   

> non cambia nulla: liblber-2.2.so.7, libldap-2.2.so.7 e libldap_r-2.2.so.7 continuano a essere linkati contro libssl.so.0.9.7 e libcrypto.so.0.9.7, e non mi so spiegare il motivo.

 io ho aggiornato openssl, rimosso a mano libssl.so.0.9.7 e libcrypto e poi ricompilato i pacchetti che davano rogne. le librerie del mio server ldap si sono linkate da sole contro libssl.so.0.9.8 e libcrypto.so.0.9.8 però io non ho  liblber-2.2.so.7, libldap-2.2.so.7 e libldap_r-2.2.so.7 ma

```

liblber-2.3.so.0 -> liblber-2.3.so.0.2.12

liblber-2.3.so.0.2.12

liblber.a

liblber.la

liblber.so -> liblber-2.3.so.0.2.12

libldap-2.3.so.0 -> libldap-2.3.so.0.2.12

libldap-2.3.so.0.2.12

libldap.a

libldap.la

libldap_r-2.3.so.0 -> libldap_r-2.3.so.0.2.12

libldap_r-2.3.so.0.2.12

libldap_r.a

libldap_r.la

libldap_r.so -> libldap_r-2.3.so.0.2.12

libldap.so -> libldap-2.3.so.0.2.12

```

----------

## Peach

 *Peach wrote:*   

> io ho appena scoperto di avere problemi con la ricompilazione di net-firewall/ipsec-tools-0.6.2-r1 come riportato anche in questo post qui

 

allora come si legge nel thread sopraccitato, riporto per corretteza che c'è un bug aperto su bugzilla e che passando alla versione masked il problema si risolve....

----------

## .:chrome:.

 *devilheart wrote:*   

> io non ho  liblber-2.2.so.7, libldap-2.2.so.7 e libldap_r-2.2.so.7

 

potrei chiederti le tue USE flag?

----------

## devilheart

 *k.gothmog wrote:*   

>  *devilheart wrote:*   io non ho  liblber-2.2.so.7, libldap-2.2.so.7 e libldap_r-2.2.so.7 
> 
> potrei chiederti le tue USE flag?

 

```
USE="amd64 X alsa avi berkdb bitmap-fonts cairo cdr cli crypt cups dbus dlloader doc dri dvd dvdr eds elibc_glibc emboss encode fam firefox fortran gdbm gif gstreamer hal input_devices_evdev input_devices_keyboard input_devices_mouse input_devices_synaptics isdnlog jpeg kde kdeenablefinal kdehiddenvisibility kernel_linux ldap libg++ linguas_it mad mp3 mpeg ncurses nls nptl nptlonly ogg opengl pam pcre pdflib perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl session spl ssl tcpd threads tiff truetype truetype-fonts type1-fonts udev unicode userland_GNU video_cards_nv video_cards_nvidia video_cards_vesa vorbis xml xorg xv zlib"
```

queste sono prese da emerge --info

```
USE="doc kdeenablefinal kdehiddenvisibility nls nptl nptlonly sse2 threads tiff -arts -esd -gnome -gpm -gtk -gtk2 -ipv6 -mikmod -oss -ruby -spell"
```

queste da make.conf

aggiungo che uso il profilo default-linux/amd64/2006.1/desktop e ho installato la versione 2.3.24-r1 di openldap

----------

## fabius

Volevo segnalare che ci possono essere problemi con pacchetti non ricompilati automaticamente da revdep-rebuild. Nel mio caso le kdelibs: infatti dopo l'aggiornamento non mi funzionava più l'autenticazione POP3 di kmail via TLS.

----------

## syntaxerrormmm

 *syntaxerrormmm wrote:*   

> Non so se è attinente, ma posto qui; nel caso non lo sia, prego un Mod di separare il post, magari con titolo 'ssh Segmentation Fault'

 Giusto per completezza, rimarco che il problema che avevo riportato in questo mio post è scomparso con i vari aggiornamenti di openssl e openssh.

Sorry per non essere stato molto attivo, avevo grossi problemi di rete; grazie a quanti mi hanno risposto.

----------

## richard77

Domanda sciocca: è normale che rieseguendo 

```
revdep-rebuild --library libcrypto.so.0.9.7
```

 mi continui a ricompilare openssl-0.9.8c-r2?

----------

## .:chrome:.

 *richard77 wrote:*   

> Domanda sciocca: è normale che rieseguendo 
> 
> ```
> revdep-rebuild --library libcrypto.so.0.9.7
> ```
> ...

 

non proprio

prova ad eliminare /usr/lib/libcrypto.so.0.9.7

----------

## X-Drum

questo update ha causato una marea di problemi :X

----------

## gutter

 *X-Drum wrote:*   

> questo update ha causato una marea di problemi :X

 

Credo che sia stati tenuti poco in considerazione dai developer i problemi che poteva creare :S

----------

## Peach

 *X-Drum wrote:*   

> questo update ha causato una marea di problemi :X

 

e cmq ti sfido a fare una transizione meno dolorosa.

L'unico sistema che non mi ha dato proprio problemi è stato un amd64, su x86 è stata una croce  :Twisted Evil: 

----------

## X-Drum

 *Peach wrote:*   

>  *X-Drum wrote:*   questo update ha causato una marea di problemi :X 
> 
> e cmq ti sfido a fare una transizione meno dolorosa.
> 
> L'unico sistema che non mi ha dato proprio problemi è stato un amd64, su x86 è stata una croce 

 

la mia era solo una constatazione,

in ogni caso anche sotto amd64 ho avuto numerosi problemi con emul-libs

ai quali si sono sommate, sempre nello stesso periodo, le problematiche

scaturite dall'upgrade di amarok e kdelibs, insomma revded-rebuild a go go!   :Twisted Evil: 

----------

## Cerberos86

i tempi sono abbastanza maturi...?

si può fare un aggiornamento senza tante "rogne"...? Non ho un server di produzione ma meno casini ci sono meglio è....   :Wink: 

Thx

----------

## X-Drum

 *Cerberos86 wrote:*   

> i tempi sono abbastanza maturi...?
> 
> si può fare un aggiornamento senza tante "rogne"...? Non ho un server di produzione ma meno casini ci sono meglio è....  
> 
> Thx

 

non capisco, in che senso "maturi" ?

in ogni caso se aggiorni (e nel caso di una macchina di produzione starei bene attento) 

preparati ad un bel revdep-rebuild, quello non lo puoi evitare in alcun modo

forse dato che è passato del tempo non dovresti avere alcuni problemi/complicazioni

che altri hanno avuto, ma in ogni caso un po di lavoro ti aspetta

----------

## .:chrome:.

 *Cerberos86 wrote:*   

> i tempi sono abbastanza maturi...?
> 
> si può fare un aggiornamento senza tante "rogne"...? Non ho un server di produzione ma meno casini ci sono meglio è....

 

le macchine in troduzione le ho aggiornate la settimana scorsa. nessun problema degno di nota

fai una cosa:

emerge --sync

emerge -u openssl

emerge -1 openssh

aggiorna SUBITO solo openssl e il minimo indispensabile, e poi SUBITO openssh, senza nemmeno che il sistema te lo chieda. e non chiudere mai le connessioni SSH mentre lo fai

così facendo non dovresti correre nessun rischio

----------

## Cerberos86

NESSUNA macchina in produzione per fortuna, la mia era solo una preoccupazione per eventuali problemi in compilazione. Dato che l'aggiornamento che devo fare riguarda sia openssl che il gccconfig 4.1, e dato che è un normale desktop, posso anke ricompilare tutto, basta che le compilazioni vadano via lisce...   :Wink: 

grazie a tutti

----------

## .:chrome:.

che io sappia, l'unico problema che potresti avere da questo punto di vista sono i pacchetti scritti in modo incompatibile con il nuovo compilatore (incompatibilità proprio a livello del codice sorgente), ma mi risulta che siano davvero rari, ormai

----------

