Please Add a FileList to your Slackbuild's repositories

[conraid]

Penso sia un problema di copyright, deve includere i sorgenti. Però la /source potrebbe essere unica per 32 e 64bit per esempio. Non mi sembra ci siano differenze tra i due rami se non per la configurazione dei kernel

[ZeroUno]

Penso sia un problema di copyright, deve includere i sorgenti. Però la /source potrebbe essere unica per 32 e 64bit per esempio. Non mi sembra ci siano differenze tra i due rami se non per la configurazione dei kernel

Odio il copyright .
Ma quì andiamo OT .

EDIT: a proposito di differenzee tra i 32 e 64 bit, i tuoi slackbuild funzionano a 32 o 64 senza modifiche? nessun pacchetto ha patch o special per un'architettura o l'altra? o lo gestisci all'interno dello sb?

[ponce]

https://raw.github.com/Ponce/slackbuild ... slack-desc

e' cosi' su slackbuilds.org, io non l'ho mica toccato
se trovi errori negli slackbuild ti conviene segnalarli al relativo maintainer (l'indirizzo lo trovi nella pagina dello slackbuild o nell'.info).

quelli modificati da me li puoi vedere nella lista dei branch.

[conraid]

EDIT: a proposito di differenzee tra i 32 e 64 bit, i tuoi slackbuild funzionano a 32 o 64 senza modifiche? nessun pacchetto ha patch o special per un'architettura o l'altra? o lo gestisci all'interno dello sb?

sì, funzionano senza modifiche, eventuali eccezioni le gestisco dentro il build, a volte con patch esterne, ma richiamate sempre da dentro il build.

Tranne Wine, dove faccio solo il pacchetto a 32bit

[ZeroUno]

@Ponce:

Una informazione sui ".info"

La entry DOWNLOAD_x86_64=url è usata là dove l'indirizzo tra x86 e x86_64 è differente o va valorizzata in ogni caso (se testi il pacchetto per 64bit).
Cioè, in caso sia presente DOWNLOAD e non DOWNLOAD_x86_64, devo pensare che il pacchetto non è stato testato a 64 bit o che il source è lo stesso e quindi è inserito solo da una parte?

[ponce]

ho visto che viene usata solo nel caso che l'oggetto da pacchettizzare sia rilasciato come binario, in modo da ripacchettizzare per slackware le versioni per le due architetture supportate al momento da slackbuilds.org: lo troverai nei casi di software proprietario o di cui e' ardua la compilazione.
per qupzilla, ad esempio, il maintainer ha deciso di pacchettizzare il binario: in questo caso specifico, pero', l'ho modificato nel mio repository in modo che compili il sorgente (per fortuna non era molto complicato).

[conraid]

Anche io compilo qupzilla e sembra tranquillo. Anzi, iniziai a compilarlo quando rekonq voleva per forza versioni nuove di kde

[conraid]

@Ponce:

Una informazione sui ".info"

La entry DOWNLOAD_x86_64=url è usata là dove l'indirizzo tra x86 e x86_64 è differente o va valorizzata in ogni caso (se testi il pacchetto per 64bit).
Cioè, in caso sia presente DOWNLOAD e non DOWNLOAD_x86_64, devo pensare che il pacchetto non è stato testato a 64 bit o che il source è lo stesso e quindi è inserito solo da una parte?

ma a te serve DOWNLOAD? Perché io uso SOURCE. Non per fare lo strano per forza, ma perché ho tutti gli script automatici che ormai usano quella, che era il nome della variabile usata dentro lo slackbuild quando facevo fare il download automatico. Però anche qui, se ti serve, ci perdo un po' di tempo appena ho voglia

[ZeroUno]

ma a te serve DOWNLOAD? Perché io uso SOURCE.

Io prendo quello che c'è
se hai source prendo source, se hai download prendo download. Il programma è flessibile.

edit: che poi ho visto che dentro lo slackbuilds.txt usi DOWNLOAD.
edit2: e considera che dove trovo slackbuilds.txt non effettuo il check sul .info
edit3: no, forse non lo skippo il check. ho visto che in alcuni .info ci sono informazioni utili che non si trovano nello slackbuilds.txt

[conraid]

ma a te serve DOWNLOAD? Perché io uso SOURCE.

Io prendo quello che c'è
se hai source prendo source, se hai download prendo download. Il programma è flessibile.

edit: che poi ho visto che dentro lo slackbuilds.txt usi DOWNLOAD.
edit2: e considera che dove trovo slackbuilds.txt non effettuo il check sul .info
edit3: no, forse non lo skippo il check. ho visto che in alcuni .info ci sono informazioni utili che non si trovano nello slackbuilds.txt

allora... questi edit mi mandano in tilt
edit1: sì, perché ho adattato lo script preso da slapt-src per creare SLACKBUILDS.TXT ai miei file, quindi il file prodotto è in sintonia con quello anche se l'origine è diversa.
edit3 (che sovrascrive l'edit2 ): nei miei .info al massimo trovi la homepage del programma in più, e come ti dicevo prima di mettere sempre l'md5, metto sha1 o sha256 (in alcuni casi anche sha512) in base alle informazioni che trovo nel sito del programma. Se non ci sono informazioni in tal senso creo solo l'md5

p.s.
ho visto, dal sorgento di slapt-src (che mi sembra il programma che ha dato vita al file SLACKBUILDS.TXT, ma potrei direi una scemata) che legge anche le variabili CATEGORY, DESCRIPTION, REQUIRES, SOURCEURL ma poi non riesco a capire bene l'uso che ne fanno (anche se per le prime 3 ci arrivo ad intuito).

Edit.
Mi sembra di capire che SOURCEURL è l'url dello slackbuild se esterno al sito, se esiste sb_location diventa diventa SOURCEURL+LOCATION

[ZeroUno]

@conraid:

da una prima implementazione della ricerca di VERSION dentro lo slackbuild.
La prima colonna è lo slackbuild; la seconda è quanto presente nello slackbuilds.txt, la terza quanto presente nello slackbuild alla riga VERSION.
La tabella riporta solo le righe trovate differenti.

Codice: Seleziona tutto

./kismet/src/kismet.SlackBuild  '2012'  '2012-03-R2'
./vifm/src/vifm.SlackBuild      '0.7.2a'        '0.7.2'
./digikam/src/digikam.SlackBuild        '2.6.0' '2.6.0-rc'
./iproute2-dev/src/iproute2-dev.SlackBuild      'VERSION=2.6.37'        '2.6.37' 
./nmapsi4/src/nmapsi4.SlackBuild        '0.3'   '${VERSIOM:-0.3}' 
./libdbi-drivers/src/libdbi-drivers.SlackBuild  '0.8.3' '0.8.3-1'
./kcoloredit/src/kcoloredit.SlackBuild  '2.0.0' '2.0.0-kde4.4.0'
./hotot/src/hotot.SlackBuild    '$(date +%Y%m%d)git'    '$(echo shellex-*.tar.gz | cut -f 1 -d . | cut -f 3 -d -)'
./inxi/src/inxi.SlackBuild      'd" "'  '$(grep "^####  version:" inxi | cut -d" " -f4)'
./krusader/src/krusader.SlackBuild      '2.4.0' '2.4.0-beta1'
./easywake/src/easywake.SlackBuild      '3'     '3-1'
./libmp4v2/src/libmp4v2.SlackBuild      'VERSION'       '2.0.0'

[conraid]

alcuni sono errori, altri purtoppo sono incongruenze perché magari uso PKGVERSION o SRCVERSION perché i programmi hanno numerazioni che makepkg non accetterebbe
hotot è così perché è git, inxi perché ricavo la versione dallo script
sistemo quel che posso

[ZeroUno]

Il controllo lo devo raffinare, ma su qualcuno hai proprio problemi

iproute2-dev su slackbuilds.txt
SLACKBUILD VERSION: VERSION=2.6.37

nmapsi4.SlackBuild:
VERSION=${VERSIOM:-0.3}

hotot su slackbuilds.txt
SLACKBUILD VERSION: $(date +%Y%m%d)git

libmp4v2 su slackbuilds.txt
SLACKBUILD VERSION: VERSION

Per quanto riguarda le tipologie di versione che makepkg rifiuterebbe, io sono solito sostituire i '-' con '_'
VERSION=1.2-3
PKGVERSION=$(echo $VERSION|sed 's/-/_/g')
ma è una scelta personale

[conraid]

sto correggendo

[ZeroUno]

@Ponce:
dei tuoi ho trovato solo questi due:
./system/BasiliskII/BasiliskII.SlackBuild '<vuoto>' '20120218'
./system/gnome-disk-utility/gnome-disk-utility.SlackBuild '<no info file>' '2.32.0'

nonostante il tool me ne segnali diversi che non sono però dei branch che mi hai indicato.