Slackware64

[Mario Vanoni]

Mi sto scocciando e penso di tornare alla 12.2!

- hddtemp non riconosce piu` gli HD (ricompilato!)
- klive.py dice md5 deprecated e non funziona
- apcupsd non trova la porta 3551, definita in /etc/services (ricompilato)
- X non parte, con xorgconfig, con dati minimali parte
- fluxbox con il vecchio .fluxbox parte, ma schermo da piangere
- mi rifiuto di provare SeaMonkey, ora sono troppo deluso

PS tutte cose che sulla 12.2 erano perfette.

[danix]

Io ho solo il problema con l'installer dei driver nvidia. pkgtool e il resto funzionano bene.
Non ho capito bene qual'è il problema però ( Corrado [-o< )..
rock

hai provato a lanciare l'installer senza usare le ncurses?? Lo consigliava Alien su linuxquestions...

[d4z_c0nf]

Io ho solo il problema con l'installer dei driver nvidia. pkgtool e il resto funzionano bene.
Non ho capito bene qual'è il problema però ( Corrado [-o< )..
rock

hai provato a lanciare l'installer senza usare le ncurses?? Lo consigliava Alien su linuxquestions...

No ma vabè, non ho problemi ad installare, pure se non si vede bene ad occhio ricordo i passaggi che fa e mi muovo di conseguenza, le scelte le riesco a fare.

@Mario:
Io ho fatto una installazione pura e non sto ricontrando problemi.
rock

[Mario Vanoni]

@Mario:
Io ho fatto una installazione pura e non sto ricontrando problemi.
rock

Anch'io, HD riformattato nella maniera piu` pesante.
Ma ho tanti problemi e non trovo soluzioni.

Perche' ricompilare ed installare nvi(1) no problems,
idem con il pacchetto sysstat, esce a giorni il 9.0.3,
ed altri, pur ricompilati, non funzionano piu`?

Ipotesi: gcc 4.3.3 non vale gcc 4.2.4,
cosa che nella LKML biasimano (tra parentesi).

[conraid]

@Mario:
Io ho fatto una installazione pura e non sto ricontrando problemi.
rock

Anch'io, HD riformattato nella maniera piu` pesante.
Ma ho tanti problemi e non trovo soluzioni.

Perche' ricompilare ed installare nvi(1) no problems,
idem con il pacchetto sysstat, esce a giorni il 9.0.3,
ed altri, pur ricompilati, non funzionano piu`?

Ipotesi: gcc 4.3.3 non vale gcc 4.2.4,
cosa che nella LKML biasimano (tra parentesi).

Ricorda che hai le lib in /lib64, quindi devi dirglielo sia al compilatore sia al configure

[danix]

mi spiegate (se lo sapete) come mai si è scelto di avere le lib in /lib64 e non in /lib?? In fondo un sistema a 64bit mi sembra normale che abbia le librerie al suo posto (/lib) e le librerie "ospiti" (quelle a 32bit) in /lib32... o mi sfugge qualcosa come al solito??

[Mario Vanoni]

Ricorda che hai le lib in /lib64, quindi devi dirglielo sia al compilatore sia al configure

Domanda da idiota, scusa tanto:

perche' sia configure che make,
con certi programmi,
trovano da soli la strada giusta,
altri compilano "me**a" senza errore?

Genio di chi ha scritto configure, o puro caso?

[Communico]

No beh per gli aggiornamenti "normali" funziona alla perfezione, ma qui serve un passo in più per il problema dei txz. Poi non so se la mia procedura sia quella "ufficialmente giusta"...Ma sinceramente mi basta che funzioni [-o< [-o<

Beh sì, io parlavo proprio del caso specifico, anche perché appena uscirà la stable mi immagino tante persone fare il passo e trovarsi spaesati.
Se ti va di scrivere qualcosa per slackpkg lo metto intanto in current-for-dummies in aggiunta alla procedura automatica, e quando esce la stable lo sposto nel wiki qui di slacky

Te l'ho mandato ora per posta perchè da pm non riuscivo ad allegare, se c'è qualcosa che non va cazziami pure

[Vito]

Riguardo le innovazioni sono scettico. Cambi epocali nel sottosistema della Slackware, cioè 64bit, compressione dei pacchetti nuova, gestore dei pacchetti sempre più presente, software tipo mplayer entrato nel ramo ufficiale, ma... il sottosistema grafico è indietro, troppo indietro. [...]

Guarda, parlo veramente per opinione personale, ma mi sembrerebbe abbastanza lineare presumere che, data la grande quantità di aggiornamenti su tutti i fronti da seguire, il team slackware abbia deciso di affrontare un problema per volta.
Immagino che, se hanno appena rilasciato la nuova distribuzione a 64 bit in current, abbiano intenzione di rilasciarla come stable alla prossima release, ma in questo caso mi auguro anche che abbiano anche intenzione di lasciarle un bel po' di tempo di maturazione in beta testing.

Certo, forse aggiornare prima il desktop environment e poi il server grafico potrebbe portare più complicazioni che non il vice-versa, ma penso sia stata più che altro una questione di tempi delle release ufficiali e roadmaps interne che il team si era prefissato.
Immagino (leggi: spero) che man mano che le ultime novità introdotte si rivelano essere stabili si proceda anche con l'aggiornamento di ciò che manca.

In fin dei conti l'ultima stable ha circa sei mesi, possiamo aspettare un altro po' per la prossima, soprattutto visto il carico di novità che porterà con sé.

P.S.: Era da quando ho visto che Amarok2 avrebbe supportato nativamente Jamendo.org che sbavavo dall'impazienza... e ora chi studia più?

Le riflessioni sollevate da Corrado e da te fanno riflettere a fondo sullo stato attuale di Slackware, e sinceramente spero che Pat non corra: c'è tempo!La 12.2 è ultrastabile e preferisco vedere una 13.0 completa piuttosto che una stabile con delle sfumature di software "retrò" (si scrive così giusto?).

[conraid]

mi spiegate (se lo sapete) come mai si è scelto di avere le lib in /lib64 e non in /lib?? In fondo un sistema a 64bit mi sembra normale che abbia le librerie al suo posto (/lib) e le librerie "ospiti" (quelle a 32bit) in /lib32... o mi sfugge qualcosa come al solito??

Scelta di Alien Bob, lo spiega su LQ se guardi il forum
Da quello che ho capito per compatibilità con binari vecchi, ma non so.
Comunque LFS consiglia di usare sia lib64 sia lib32 e fare dei link simbolici per quella utilizzata

Ricorda che hai le lib in /lib64, quindi devi dirglielo sia al compilatore sia al configure

Domanda da idiota, scusa tanto:

perche' sia configure che make,
con certi programmi,
trovano da soli la strada giusta,
altri compilano "me**a" senza errore?

Genio di chi ha scritto configure, o puro caso?

Mario non lo so, so che per esempio negli slackbuild va specificato parametri diversi a seconda se ti trovi su slack64 o slack32
Per esempio una cosa simile

Codice: Seleziona tutto

LDFLAGS="-L/usr/lib64 -L/lib64" \
./configure \
  --prefix=/usr \
  --libdir=/usr/lib64 \

se poi lo prende da solo non so, ma io ho iniziato a fare gli slackbuild così vedendo quelli di Alien Bob, che è quello che ha curato la versione a 64 di Slackware
Non tutti i software ne hanno bisogno penso

[conraid]

No beh per gli aggiornamenti "normali" funziona alla perfezione, ma qui serve un passo in più per il problema dei txz. Poi non so se la mia procedura sia quella "ufficialmente giusta"...Ma sinceramente mi basta che funzioni [-o< [-o<

Beh sì, io parlavo proprio del caso specifico, anche perché appena uscirà la stable mi immagino tante persone fare il passo e trovarsi spaesati.
Se ti va di scrivere qualcosa per slackpkg lo metto intanto in current-for-dummies in aggiunta alla procedura automatica, e quando esce la stable lo sposto nel wiki qui di slacky

Te l'ho mandato ora per posta perchè da pm non riuscivo ad allegare, se c'è qualcosa che non va cazziami pure

domani guardo, ora non ho accesso alla posta

[conraid]

Riguardo le innovazioni sono scettico. Cambi epocali nel sottosistema della Slackware, cioè 64bit, compressione dei pacchetti nuova, gestore dei pacchetti sempre più presente, software tipo mplayer entrato nel ramo ufficiale, ma... il sottosistema grafico è indietro, troppo indietro. [...]

Guarda, parlo veramente per opinione personale, ma mi sembrerebbe abbastanza lineare presumere che, data la grande quantità di aggiornamenti su tutti i fronti da seguire, il team slackware abbia deciso di affrontare un problema per volta.
Immagino che, se hanno appena rilasciato la nuova distribuzione a 64 bit in current, abbiano intenzione di rilasciarla come stable alla prossima release, ma in questo caso mi auguro anche che abbiano anche intenzione di lasciarle un bel po' di tempo di maturazione in beta testing.

Certo, forse aggiornare prima il desktop environment e poi il server grafico potrebbe portare più complicazioni che non il vice-versa, ma penso sia stata più che altro una questione di tempi delle release ufficiali e roadmaps interne che il team si era prefissato.
Immagino (leggi: spero) che man mano che le ultime novità introdotte si rivelano essere stabili si proceda anche con l'aggiornamento di ciò che manca.

In fin dei conti l'ultima stable ha circa sei mesi, possiamo aspettare un altro po' per la prossima, soprattutto visto il carico di novità che porterà con sé.

P.S.: Era da quando ho visto che Amarok2 avrebbe supportato nativamente Jamendo.org che sbavavo dall'impazienza... e ora chi studia più?

non avevo proprio notato questo tuo post, per fortuna Vito lo ha citato

Se ci pensi anche al 12.2 come ambiente grafico è indietro, infatti fu nella -current della 12.2 che nacquero i problemi e che Pat scrisse

While there are still some docs that need updating and probably a few more
tweaks and updates here and there, everything is mostly in place for the next
stable release, Slackware 12.2. The versions of major components like X and
the kernel can be considered frozen. Anything major that we haven't done yet
will probably wait for the release after this next one. As Slackware 12.2 is
only a 0.1 version bump, we're trying to focus on making it better without
causing instability or losing compatibility with Slackware 12.1 wherever
possible. Invasive changes like the new X (that will require changes to
xorg.conf) and merging KDE4 should probably wait for Slackware 13.0.

e prima ancora

These are some of the more important updates for X.Org. For the last
several days we have been building and testing the very newest X updates, and
it seems that the more intrusive updates are probably best left to develop
until sometime after the coming -stable Slackware 12.2 release. Those will
require a lot of testing and some things don't seem to be quite there yet.
"X -configure" is hanging the console, DRI is not yet working on all the
hardware tested, and the new xorg-server will render most existing xorg.conf
files non-functional until several changes are made.

Se prima erano cambiamenti invasivi ed instabilità a fermare la cosa, ok, ma adesso tutto il resto si sta adeguando alle nuove features. Compreso il kernel.
Poi da quello che ho capito Alien Bob ha curato kde4 e slack64 (8 mesi di sviluppo di cui 4 anche di testing), RW xfce, udev+hal, PP su slackpkg, ed altri su altro ancora. Pat fa ancora la maggior parte del lavoro, e sta testando con RW xorg, ma il team è sempre più importante e si dividono i compiti.

Questo per dire che forse mettere xorg nuovo in current (e farcelo testare) non sarebbe stato male, hai più feedback no?
Ma naturalmente tutto in mia umile opinione

[Vito]

Forse lo sta già testando? così come stava preparando già slackware64?

Spero si focalizzi su Xorg ora che ci sono stati questi "pesanti" cambiamenti...
Comunque anche secondo me la 13.0 slitta per settembre/ottobre (come avevo letto qualche post più sopra).

[conraid]

Forse lo sta già testando? così come stava preparando già slackware64?

Certo che si, su slackers.it ho anche citato un passo di RW, ma appunto dalle sue parole mi nascono i dubbi

I’ve done a bit of work on new X, and in my testing here, it seems mostly fine. It’s still in a bit of flux, and I’m almost sure that the jump is too big to make at this point in the development cycle. I don’t want to say too much more, because I don’t want to dash any hopes or get any hopes up unnecessarily, so I’ll just say this: it’s on our radar. In other words, we are aware that newer Xorg is available, but at the same time, the current stuff we have still works.

[Vito]

Grazie Corrado!
Insomma spero veramente che riescano ad inserirlo a breve in questa current,insomma porterebbe una nuova ventata di entusiasmo