proposta: nuovi pacchetti SBoSl ...
Moderatore: Staff
Regole del forum
1) Citare in modo preciso il nome del pacchetto.
2) Specificare se discussione/suggerimento o richiesta d'aiuto.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
1) Citare in modo preciso il nome del pacchetto.
2) Specificare se discussione/suggerimento o richiesta d'aiuto.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
- Loris
- Admin
- Messaggi: 7730
- Iscritto il: lun 31 mar 2003, 0:00
- Nome Cognome: Loris Vincenzi
- Località: Gradisca D'Isonzo
- Contatta:
Re: proposta: nuovi pacchetti SBoSl ...
Non c'è perché nessuno ancora l'ha fatto, come dicevo prima... siamo in pochi a pacchettizzare
"Ho una testa piuttosto balzana e comunque non sono quello che credete" - Roger Keith Barrett
- Vito
- Staff
- Messaggi: 4182
- Iscritto il: mar 5 dic 2006, 17:28
- Nome Cognome: Vito
- Desktop: MacOS
- Località: Monaco (DE)
- Contatta:
Re: proposta: nuovi pacchetti SBoSl ...
purtroppo a pacchettizzare siamo in pochi,
non sarebbe il caso di focalizzarsi sull'ingrandire il repo "ufficiale"?
non sarebbe il caso di focalizzarsi sull'ingrandire il repo "ufficiale"?
"Stat rosa pristina nomina, nomina nuda tenemus." [ Umberto Eco - Il nome della rosa]
"Faber est suae quisque fortunae ." [ Appio Claudio Cieco]
"Faber est suae quisque fortunae ." [ Appio Claudio Cieco]
-
- Master
- Messaggi: 1645
- Iscritto il: lun 16 lug 2007, 17:39
- Slackware: 15.0 64bit
- Kernel: 5.15.27
- Desktop: kde
- Località: Roma
Re: proposta: nuovi pacchetti SBoSl ...
forse secondo me stiamo facendo un po' di confusione.
zoros, non sapendo giustamente come funziona il manteniimento del repository, ha suggerito di usare slackbuilds di terze parti per velocizzare il lavoro.
peccato che il vero problema non sia tanto quello.. perchè alle volte ci sbircio pure io dentro gli slackbuilds esterni.. ma è una questione proprio di manodopera
forse se facessimo una conta di chi pacchettizza in modo piu' o meno regolare, si renderebbe conto del perchè il repo per quanto ci si impegni, necessita di tempo maggiore per raggiungere un determinato numero di pacchetti.
per questo io ho suggerito che forse un modo per rendere il servizio sempre migliore è quello di creare una sezione nel forum, o meglio ancora un form da compilare, dove si richiede un determinato pacchetto..
visto che si è sollevato il problema sono andato a farmi un giro alla 'concorrenza' e ho visto che c'e' quasi sempre un modo per richiedere pacchettizzazioni.
in questo modo noi pacchettizzatori continuiamo la normale attività, però con un occhio a quelle che sono le esigenze della comunità
zoros, non sapendo giustamente come funziona il manteniimento del repository, ha suggerito di usare slackbuilds di terze parti per velocizzare il lavoro.
peccato che il vero problema non sia tanto quello.. perchè alle volte ci sbircio pure io dentro gli slackbuilds esterni.. ma è una questione proprio di manodopera
forse se facessimo una conta di chi pacchettizza in modo piu' o meno regolare, si renderebbe conto del perchè il repo per quanto ci si impegni, necessita di tempo maggiore per raggiungere un determinato numero di pacchetti.
per questo io ho suggerito che forse un modo per rendere il servizio sempre migliore è quello di creare una sezione nel forum, o meglio ancora un form da compilare, dove si richiede un determinato pacchetto..
visto che si è sollevato il problema sono andato a farmi un giro alla 'concorrenza' e ho visto che c'e' quasi sempre un modo per richiedere pacchettizzazioni.
in questo modo noi pacchettizzatori continuiamo la normale attività, però con un occhio a quelle che sono le esigenze della comunità
- Vito
- Staff
- Messaggi: 4182
- Iscritto il: mar 5 dic 2006, 17:28
- Nome Cognome: Vito
- Desktop: MacOS
- Località: Monaco (DE)
- Contatta:
Re: proposta: nuovi pacchetti SBoSl ...
bella idea miklos,
magari una cosa simile a pkgreports ,solo per le richieste!
Anche se effettivamente c'è una sezione del forum dove è possibile richiedere i pacchetti.
magari una cosa simile a pkgreports ,solo per le richieste!
Anche se effettivamente c'è una sezione del forum dove è possibile richiedere i pacchetti.
"Stat rosa pristina nomina, nomina nuda tenemus." [ Umberto Eco - Il nome della rosa]
"Faber est suae quisque fortunae ." [ Appio Claudio Cieco]
"Faber est suae quisque fortunae ." [ Appio Claudio Cieco]
- zoros
- Linux 4.x
- Messaggi: 1361
- Iscritto il: lun 28 mag 2007, 22:51
- Nome Cognome: Fabio`Zorba`
- Slackware: 14.1
- Kernel: 3.10.30-smp
- Desktop: KDE-3.5(works!)
- Località: Gorizia
- Contatta:
Re: proposta: nuovi pacchetti SBoSl ...
ho letto i vari interventi, certo, non ho ancora chiaro il lavoro che c'è sotto ... osservavo questo:
se il repository (da browser) si presenta con un filesystem, mi aspetto che ad ogni nuova release venga riprodotto il directory tree della precedente ... con tanti alloggiamenti vuoti da riempire progressivamente ... ma non è così, probabilmente per un motivo tecnico (ciò che si vede da browser è comunque "virtuale") ... però se ci fossero almeno gli spazi vuoti si potrebbero riempire prima o poi ...
quindi più che la richiesta di un pacchetto si potrebbe richiedere di creare lo spazio per ospitarlo ... se nel mentre ci mettiamo un t*z provvisorio io non ci vedrei niente di male ...
cioè: non può essere che anche le seguenti condizioni operative condizionino i tempi?
se il repository (da browser) si presenta con un filesystem, mi aspetto che ad ogni nuova release venga riprodotto il directory tree della precedente ... con tanti alloggiamenti vuoti da riempire progressivamente ... ma non è così, probabilmente per un motivo tecnico (ciò che si vede da browser è comunque "virtuale") ... però se ci fossero almeno gli spazi vuoti si potrebbero riempire prima o poi ...
quindi più che la richiesta di un pacchetto si potrebbe richiedere di creare lo spazio per ospitarlo ... se nel mentre ci mettiamo un t*z provvisorio io non ci vedrei niente di male ...
cioè: non può essere che anche le seguenti condizioni operative condizionino i tempi?
vorrei riavere le mie firme ...
- Vito
- Staff
- Messaggi: 4182
- Iscritto il: mar 5 dic 2006, 17:28
- Nome Cognome: Vito
- Desktop: MacOS
- Località: Monaco (DE)
- Contatta:
Re: proposta: nuovi pacchetti SBoSl ...
I pacchetti vanno compilati su macchine "pulite" senza altri pacchetti.
Il nostro problema effettivo è il numero di persone che possono mettere a disposizione una macchina (anche virtuale, io faccio così!) e del tempo per compilare/ricompilare i pacchetti.
Il nostro problema effettivo è il numero di persone che possono mettere a disposizione una macchina (anche virtuale, io faccio così!) e del tempo per compilare/ricompilare i pacchetti.
"Stat rosa pristina nomina, nomina nuda tenemus." [ Umberto Eco - Il nome della rosa]
"Faber est suae quisque fortunae ." [ Appio Claudio Cieco]
"Faber est suae quisque fortunae ." [ Appio Claudio Cieco]
- ZeroUno
- Staff
- Messaggi: 5441
- Iscritto il: ven 2 giu 2006, 14:52
- Nome Cognome: Matteo Rossini
- Slackware: current
- Kernel: slack-current
- Desktop: ktown-latest
- Distribuzione: 01000000-current
- Località: Roma / Castelli
- Contatta:
Re: proposta: nuovi pacchetti SBoSl ...
Eliminare queste condizioni operative equivale ad eliminare la peculiarità primaria del repository slacky: l'affidabilità! (comunque, per info, da allora sono stati fatti molti passi avanti per migliorare sia la velocità di pacchettizzazione che la qualità dei pacchetti)zoros ha scritto:cioè: non può essere che anche le seguenti condizioni operative condizionino i tempi?
Personalmente il mio calo in quantità di pacchetti è proporzionale alla distanza da stable a current.
Ultimamente ho poco tempo, ma all'uscita di una stable pacchettizzo abbastanza, sia pacchetti che uso normalmente che quelli che non uso.
Man mano che current avanza pacchettizzo sempre meno nuovi pacchetti perchè devo fare doppio lavoro: una versione per current (per me) e una versione per stable (per slacky).
Se anche utilizzassi slackbuild già fatti e testati da altri sia per current che per stable, comunque devo farmi tutto questo doppio lavoro.
Il problema di chi usa current sta, tra l'altro, anche nel fatto che più ci si discosta da stable e meno si scarica da stable (perchè si perde compatibilità)
Allora la soluzione non starebbe nell'inserire un 'unofficial' repository ma un repository per current, ma non so questo quanto sia accettabile la cosa.
Sarebbe da informarsi su che versione di slackware (stable/current) usa mediamente la gente che scarica da slacky.
Ci sono pacchetti che devono essere categoricamente su stable (squid, postfix, e tutti i programmi diretti ai server perchè è fuori standard che un sistemista installi una current sui propri server; per tali pacchetti io consentirei anche al pacchettizzatore di aggiornare i repository precedenti all'attuale stable; personalmente ho ancora un server con slackware 9 e uno con 10.2), mentre altri (quelli diretti al desktop) li farei principalmente per current.
Il rischio è che il repo stable rimanga povero. Il vantaggio è che la somma dei repository stable+current sarebbe indubbiamente più grande dell'attuale stable.
Sarebbe utile che chi di noi può metta a disposizione degli altri una macchina virtuale? (ovviamente il pacchettizzatore si impegnerebbe a non abusare di tale disponibilità e si limiti a usare la macchina per pacchettizzare)Vito ha scritto:Il nostro problema effettivo è il numero di persone che possono mettere a disposizione una macchina (anche virtuale, io faccio così!) e del tempo per compilare/ricompilare i pacchetti.
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
- targzeta
- Iper Master
- Messaggi: 6629
- Iscritto il: gio 3 nov 2005, 14:05
- Nome Cognome: Emanuele Tomasi
- Slackware: 64-current
- Kernel: latest stable
- Desktop: IceWM
- Località: Carpignano Sal. (LE) <-> Pisa
Re: proposta: nuovi pacchetti SBoSl ...
Stavo pensando anche io ad una soluzione del genere. Anche io sono in current e non posso pacchettizzare. Potrei virtualizzare una stable...ma sul notebook non so se me la sento . L'idea comunque rimane abbastanza buona, si potrebbe addirittura pacchettizzare per 32 e 64 bit virtualizzando entrambe le stable.ZeroUno ha scritto:...Sarebbe utile che chi di noi può metta a disposizione degli altri una macchina virtuale? (ovviamente il pacchettizzatore si impegnerebbe a non abusare di tale disponibilità e si limiti a usare la macchina per pacchettizzare)
Emanuele
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
- ZeroUno
- Staff
- Messaggi: 5441
- Iscritto il: ven 2 giu 2006, 14:52
- Nome Cognome: Matteo Rossini
- Slackware: current
- Kernel: slack-current
- Desktop: ktown-latest
- Distribuzione: 01000000-current
- Località: Roma / Castelli
- Contatta:
Re: proposta: nuovi pacchetti SBoSl ...
Comunque la soluzione migliore per pacchettizzare rimane sempre e comunque un chroot.spina ha scritto:Potrei virtualizzare una stable...ma sul notebook non so se me la sento . L'idea comunque rimane abbastanza buona, si potrebbe addirittura pacchettizzare per 32 e 64 bit virtualizzando entrambe le stable.
Per un tempo ho avuto sia un chroot a 32bit che un chroot a 64bit. Garantisco che per oltre il 90% dei casi non si riscontrano problemi. E l'unico caso in cui si verificano (chromium), beh... boot in chroot e risolvi.
Però a quel punto dovevo pacchettizzare 3 volte (una per 64current, per me, una per stable64 e una per stable32).
Packages finder: slakfinder.org | Slackpkg+, per aggiungere repository a slackpkg
Codice: Seleziona tutto
1011010 1100101 1110010 1101111 - 0100000 - 1010101 1101110 1101111
-
- Master
- Messaggi: 1645
- Iscritto il: lun 16 lug 2007, 17:39
- Slackware: 15.0 64bit
- Kernel: 5.15.27
- Desktop: kde
- Località: Roma
Re: proposta: nuovi pacchetti SBoSl ...
io pacchettizzo tramite una virtualbox a 64bit... gli ho riservato 500Mb di ram e 20Gb di harddisk (me lo posso permettere ) e cosi' la posso lasciare in background a compilare senza troppi patemi, mentre faccio altro.
poi ogni volta che il repo viene aggiornato la ripulisco tramite slackpkg e vado avanti...
poi ogni volta che il repo viene aggiornato la ripulisco tramite slackpkg e vado avanti...
- lablinux
- Linux 4.x
- Messaggi: 1212
- Iscritto il: gio 27 nov 2008, 12:23
- Desktop: Gnome
- Distribuzione: Debian testing
- Località: Rho
Re: proposta: nuovi pacchetti SBoSl ...
Ecco arriva Loris con un solo messaggio e blocca la discussione. Il solito guastafeste
La mi domanda è semplice, perché prendere gli slackbuild da salckbuilds o da slackers e portarli su slacky? Solo per avere il binario? Ma per questo ci vogliono solo pochi minuti. Per essere compatibile con slackyd? Questo sarebbe un anltro punto di forza di slackyd... dargli la capacità di cercare anche i sorgenti da compilare da archivi come slackbuilds o slackers.
La mi domanda è semplice, perché prendere gli slackbuild da salckbuilds o da slackers e portarli su slacky? Solo per avere il binario? Ma per questo ci vogliono solo pochi minuti. Per essere compatibile con slackyd? Questo sarebbe un anltro punto di forza di slackyd... dargli la capacità di cercare anche i sorgenti da compilare da archivi come slackbuilds o slackers.
-
- Master
- Messaggi: 1645
- Iscritto il: lun 16 lug 2007, 17:39
- Slackware: 15.0 64bit
- Kernel: 5.15.27
- Desktop: kde
- Località: Roma
Re: proposta: nuovi pacchetti SBoSl ...
si certo.. ma a che pro' se poi a pacchettizzare siamo in 3(numero puramente casuale)?!?!?!lablinux ha scritto:Ecco arriva Loris con un solo messaggio e blocca la discussione. Il solito guastafeste
La mi domanda è semplice, perché prendere gli slackbuild da salckbuilds o da slackers e portarli su slacky? Solo per avere il binario? Ma per questo ci vogliono solo pochi minuti. Per essere compatibile con slackyd? Questo sarebbe un anltro punto di forza di slackyd... dargli la capacità di cercare anche i sorgenti da compilare da archivi come slackbuilds o slackers.
mi sa che zoros ha fatto una giustissima osservazione.. pero' forse pochi hanno capito la vera realta' e il vero problema.. siccome siamo pochi a mantenere il repository il tempo che ci si mette per portarlo ad un livello almeno pari a quelli precedenti e maggiore
i suggerimenti fatti in questo post ci stanno tutti, per carità.. pero' in base alla mia esperienza dico che:
1) per come è organizzato il repository è piu' facile ripartire da zero ad ogni nuova stable perchè paradossalmente le verifiche da fare in caso contrario sarebbero piu' lunghe e quindi passibili di errori. @zoros esiste un sistema che tiene traccia di tutti i pacchetti.. i pacchetti da fare si sanno.. è solo che si procede per priorità.. per questo consigliavo di segnalare in qualche modo le esigenze
2) usare slackbuilds di terze parti puo' non essere altrettanto d'aiuto.. molti slackbuilds che guardo in giro hanno, in base al repository di appartenenza, opzioni di compilazione che non sempre sono complete/seguono la filosofia del nostro (uno su tutti opencv.. che quando lo pacchettizzai io si trovava in giro solo con supporto a versioni di ffmpeg arcaiche.. oppure webkit.. qui' noi abbiamo una versione molto piu' recente di quanto si riesca a trovare in giro)
- zoros
- Linux 4.x
- Messaggi: 1361
- Iscritto il: lun 28 mag 2007, 22:51
- Nome Cognome: Fabio`Zorba`
- Slackware: 14.1
- Kernel: 3.10.30-smp
- Desktop: KDE-3.5(works!)
- Località: Gorizia
- Contatta:
Re: proposta: nuovi pacchetti SBoSl ...
ci sono stati parecchi interventi interessanti in questo thread ... mi riferisco alle considerazioni tecniche ... e mi pare siano uscite anche delle idee nuove ...
la mia proposta era più "politica" che tecnica: per me è meglio un repository "sporco" dove però trovi i pacchetti, piuttosto che non trovarli ... tecnicamente io dico che, in particolare su Slackware, ci sono ampi margini di compatibilità tra pacchetti compilati su versioni diverse ...
la mia proposta era più "politica" che tecnica: per me è meglio un repository "sporco" dove però trovi i pacchetti, piuttosto che non trovarli ... tecnicamente io dico che, in particolare su Slackware, ci sono ampi margini di compatibilità tra pacchetti compilati su versioni diverse ...
vorrei riavere le mie firme ...
-
- Packager
- Messaggi: 2021
- Iscritto il: ven 4 giu 2010, 10:27
- Nome Cognome: Luca De Pandis
- Distribuzione: macOS/OpenBSD
- Località: Lecce/Bergamo
Re: proposta: nuovi pacchetti SBoSl ...
Sarebbe un'ottima cosa.ZeroUno ha scritto:Sarebbe utile che chi di noi può metta a disposizione degli altri una macchina virtuale? (ovviamente il pacchettizzatore si impegnerebbe a non abusare di tale disponibilità e si limiti a usare la macchina per pacchettizzare)Vito ha scritto:Il nostro problema effettivo è il numero di persone che possono mettere a disposizione una macchina (anche virtuale, io faccio così!) e del tempo per compilare/ricompilare i pacchetti.
Personalmente, stando su FreeBSD non ho più la Slackware in chroot per creare pacchetti. Infatti è da un pò che non mi dedico al repository.
Purtroppo come hanno detto Loris e gli altri, i packagers attivi sono veramente pochi. Il problema è che il lavoro di pacchettizzazione richiede troppo tempo: oltre ai pacchetti del repository immediatamente precedente (attualmente 13.1), rimangono quelli dei repository più vecchi (13.0 in giù).
Inoltre IMHO si perde troppo tempo a riadattare gli SlackBuild ai nuovi template. Secondo me, ne andrebbe scelto uno e mantenuto definitivamente.
Non è per polemica, ma IMHO si perde troppo tempo a riscrivere il tutto ogni volta.
-
- Packager
- Messaggi: 407
- Iscritto il: dom 1 nov 2009, 12:53
- Nome Cognome: Tommaso D'Anna
- Slackware: 13.37
- Kernel: 2.6.37.6
- Desktop: xfce
Re: proposta: nuovi pacchetti SBoSl ...
Ragazzi, io sono un ex pacchettizzatore di slacky (forse mi conoscete meglio col nick tasodan).
Da tempo non bazzico su questo forum perché mi sono dovuto laureare, e inoltre sono approdato alle più comode chakra e poi ad archlinux.
Diciamo che l'unico legame che mi resta con slackware è l'affezione che nutro per questa community, slacky.eu... lasciatemelo dire ragazzi, ma Pat ha fatto una distribuzione stupenda trascurando una cosa fondamentale: una community ufficiale. Per questo mancano i pacchetti, per questo manca (spesso) il supporto, per questo mancano tante cose.
Perché non c'è un forum ufficiale? Perché non c'è un 3rd-party-repository ufficiale?
Quelli di SBo sono bravi, quelli di gnomeslackbuild pure, anche noi siamo bravini. Perché tuttavia dobbiamo tutti lavorare a progetti diversi e disperderci, e addirittura "vergognarci" di scopiazzare l'un l'altro?
Questi problemi succedono perché i pochi utenti (come me e voi) che vogliono contribuire sono lasciati senza una guida.
Continuando così sarete sempre troppo pochi, e un giorno slackware sparirà.
Non sarebbe forse l'ora di far qualcosa perché Pat, invece di perder tempo su elucubrazioni filosofiche - tipo mettere pam o meno nella slack (cosa che ha creato non pochi problemi ai pacchettizzatori) - faccia qualcosa di pratico e si decida a creare questa benedetta community ufficiale e salvare questa distro?
Tanta gente, come me, non aspetta altro per tornare.
Da tempo non bazzico su questo forum perché mi sono dovuto laureare, e inoltre sono approdato alle più comode chakra e poi ad archlinux.
Diciamo che l'unico legame che mi resta con slackware è l'affezione che nutro per questa community, slacky.eu... lasciatemelo dire ragazzi, ma Pat ha fatto una distribuzione stupenda trascurando una cosa fondamentale: una community ufficiale. Per questo mancano i pacchetti, per questo manca (spesso) il supporto, per questo mancano tante cose.
Perché non c'è un forum ufficiale? Perché non c'è un 3rd-party-repository ufficiale?
Quelli di SBo sono bravi, quelli di gnomeslackbuild pure, anche noi siamo bravini. Perché tuttavia dobbiamo tutti lavorare a progetti diversi e disperderci, e addirittura "vergognarci" di scopiazzare l'un l'altro?
Questi problemi succedono perché i pochi utenti (come me e voi) che vogliono contribuire sono lasciati senza una guida.
Continuando così sarete sempre troppo pochi, e un giorno slackware sparirà.
Non sarebbe forse l'ora di far qualcosa perché Pat, invece di perder tempo su elucubrazioni filosofiche - tipo mettere pam o meno nella slack (cosa che ha creato non pochi problemi ai pacchettizzatori) - faccia qualcosa di pratico e si decida a creare questa benedetta community ufficiale e salvare questa distro?
Tanta gente, come me, non aspetta altro per tornare.