Programma per calibrare una LIM

Reduce da http://forum.fedoraonline.it/viewtopic.php?id=24592 discussione, stante il fatto che xinput_calibrator non sembra funzionare (e che non è stato più aggiornato da Fedora 13), ho scritto un programma in python3 (usando le Gtk 3) per calibrare una LIM.
Se qualcuno lo vuole provare (io ho potuto provarlo solo su una LIM, dove funziona), lo trovate http://www.mathhelp.eu/software/calibratetouchscreen/calibratetouchscreeninstall.html.

Vorrei sapere, se possibile, se le dipendenze che ho inserito nel file spec sono corrette, o se ho dimenticato qualcosa.

I moduli importati nel programma python sono cairo, cgi, datetime, Gdk, gi.repository, Gtk, math, os, subprocess, sys, webbrowser. Le Gtk usate sono le 3.0; inoltre eseguo i comandi esterni xinput e locale.

Io ho inserito queste dipendenze:

Requires: python3 #/usr/bin/python3 Requires: gtk3 #/usr/lib64/gtk-3.0 ? Requires: xorg-x11-server-utils #/usr/bin/xinput Requires: glibc-common #/usr/bin/locale Requires: python3-gobject-base #/usr/lib64/python3.5/site-packages/gi/repository Requires: python3-cairo #/usr/lib64/python3.5/site-packages/cairo

Ho dimenticato (o sbagliato) qualcosa?

Potresti creare un repository su Copr e a caricare il tuo srpm, così da assicurarti che il pacchetto venga generato senza problemi e facilitare la diffusione del tuo programma.
Non credo valga la pena preoccuparsi della compatibilità per Python 2 ormai. Si potrebbe poi proporlo per l’inclusione in Fedora, merita di essere conosciuto (e complimenti per lo spirito di condivisione e la determinazione) :slight_smile:

Il repository, al momento, ce l’ho sul mio sito:

[code]$ cat /etc/yum.repos.d/mathhelp.repo
[mathhelp]
name=www.mathhelp.eu repository
baseurl=http://www.mathhelp.eu/software/repo/$basearch/
enabled=0

[mathhelp-source]
name=www.mathhelp.eu repository - Source
baseurl=http://www.mathhelp.eu/software/repo/source/
enabled=0[/code]

Come funziona su Copr, e cosa comporterebbe di diverso? È un passaggio indispensabile per proporre di inserire un nuovo programma nei repository?
Non capisco perché caricando il file rpm sorgente su copr ci si assicura che il pacchetto “venga generato senza problemi”. Se genero l’rpm nel mio PC, cosa cambia?
Scusa per la mia ignoranza, ma ho una idea estremamente vaga su cosa sia Copr.

E infatti non è quello il mio problema, avendo usato python3 e Gtk 3.
Ho solo il dubbio che esista, come dipendenza, qualcosa che è di fatto installato nel mio computer, e che non ho inserito esplicitamente come dipendenza nel file spec (in particolare penso agli import).
Per esempio quest’estate, installando Fedora dal CD su un portatile che avevo fatto riparare, mi sono accorto che un altro mio programma (questa volta scritto in python2) non partiva: infatti non era stato installato pygtk2, e non avevo inserito il “Requires: pygtk2” nel file spec.

A me non dispiacerebbe affatto, sia per questo che per gli http://www.mathhelp.eu/software/index.html programmi che ho scritto (in particolare, MenuApps e SpitAudioTracks). Ma penso che avrei bisogno di qualcuno che si occupi di vagliare la corrispondenza di alcuni dettagli agli standard richiesti: per esempio, la licenza deve essere contenuta in un file, o va bene linkarla come ho fatto? I files sorgenti basta che siano nel file src.rpm, o devono necessariamente essere pubblicati a parte?

Se qualcuno si offre…

Il repository, al momento, ce l’ho sul mio sito:[/quote]

Visto, hai fatto tanto; con copr semplifichi ancor di più.

Dato un srpm, Copr installa le dipendenze, fa il build, mette nel repository e via. C’è un comando su dnf per abilitarlo al volo, puoi compilare su altre architetture ed è uno dei vari modi per essere sicuri che effettivamente il pacchetto possa essere compilato ed installato con le dipendenze specificate.

No.

Il problema consiste nella riproducibilità del build e dell’installazione. Se ti dimentichi una dipendenza, che però è già installata sul tuo pc, se utilizzi rpmbuild liscio non ti accorgerai del problema. Sistemi come koji, copr o mock (se vuoi qualcosa da utilizzare il locale - ottima soluzione durante la stesura del file spec o se devi fare modifiche importanti) creano un ambiente nuovo per ogni build.

[quote=marcomotta]

A me non dispiacerebbe affatto, sia per questo che per gli http://www.mathhelp.eu/software/index.html programmi che ho scritto (in particolare, MenuApps e SpitAudioTracks). Ma penso che avrei bisogno di qualcuno che si occupi di vagliare la corrispondenza di alcuni dettagli agli standard richiesti: per esempio, la licenza deve essere contenuta in un file, o va bene linkarla come ho fatto? I files sorgenti basta che siano nel file src.rpm, o devono necessariamente essere pubblicati a parte?

Se qualcuno si offre…[/quote]

L’ideale sarebbe mettere tutto su un repository GitHub/GitLab, ma per ora un tarball va più che bene. La licenza deve essere specificata nel file spec nel relativo campo e deve essere allegata in un file, di solito chiamato LICENSE o COPYING. Ricordarsi di mettere tutto in %files in questo modo (esempio):

%files file_da_includere %doc LICENSE README

Di solito in testa ad ogni sorgente si mette “questo file fa parte del programma 1-2-3-stella copyright vattelapesca”: https://www.gnu.org/licenses/gpl-howto.html

Il file src.rpm deve contenere esclusivamente file sorgenti. E’ chiaro che in un pacchetto Python, non essendoci spesso compilazione, la differenza tra src.rpm ed rpm non sia marcata.

[quote=frafra]La licenza deve essere specificata nel file spec nel relativo campo e deve essere allegata in un file, di solito chiamato LICENSE o COPYING. Ricordarsi di mettere tutto in %files in questo modo (esempio):

%files file_da_includere %doc LICENSE README

Di solito in testa ad ogni sorgente si mette “questo file fa parte del programma 1-2-3-stella copyright vattelapesca”: https://www.gnu.org/licenses/gpl-howto.html
[/quote]
Allora, cominciamo da qui. Quale licenza è preferibile usare, secondo te? Io ho scritto GPL, ma forse è meglio indicare la versione 3? Non so neppure che differenze ci siano, a dire la verità.
Nel file spec, se uso la versione 3, al posto di “License: GPL”, devo mettere “License: GPLv3”?
Per quanto riguarda il contenuto del file LICENSE, va bene copiare pari pari quello che viene riportato https://www.gnu.org/licenses/gpl-3.0.txt, o devo correggere o integrare qualcosa?
Poi, il file LICENSE deve essere nella root del tar.gz perché venga trovato durante la creazione dell’rpm, o dove altro? Al momento il mio tar.gz contiene tutti i files nella cartella /calibrateTouchScreen-0.9/calibrateTouchScreen, in quanto così mi limito, nella sezione %install, a copiare la cartella calibrateTouchScreen in /usr/share. Quindi penso che debba essere /calibrateTouchScreen-0.9/LICENSE, o sbaglio?

Io rilascio il mio codice sotto GPLv3 o AGPLv3 nel caso si tratti di un applicativo web.
La differenza rispetto alla 2 (vado a memoria) è che protegge da problemi di brevetti (uno non può rilasciare un programma sotto GPLv3 e denunciarti perché violi un suo brevetto) ed evita la cosiddetta tivo-izazione (neologismo legato ai registratori TiVo, dove il software era libero, ma non potevi modificarlo perché il sistema ti impediva di fare il boot di kernel non autorizzat).

Di conseguenza metterei un normale:

License:	GPLv3+

Per quanto riguarda il file LICENSE: basta copiare quel file nella root del sorgente.
Ti segnalo che il campo Source0 è errato: serve il percorso completo per raggiungere il tarball del sorgente.

Intanto ti ringrazio per le risposte.

Per quanto riguarda le dipendenze, ho usato mock, che si è rivelato utilissimo per trovare i BuildRequires mancanti; un po’ meno per i Requires.
Ho provato a togliere la riga “Requires: pygtk2” ad un altro programma scritto in python 2 che usa le Gtk: mock non ha fatto una piega, ma sono sicuro che senza quella riga il programma viene installato, ma va in errore durante gli import (sospetto che, con un programma interpretato come python, sia necessario avere qualche cautela in più con le dipendenze e in particolare con gli import, e che gli strumenti automatici possano non essere del tutto efficaci).

Per quanto riguarda la licenza, ho fatto così:

  1. ho inserito “License: GPLv3+” nel file spec;
  2. ho inserito come “%license COPYING” il testo di https://www.gnu.org/licenses/gpl-3.0.txt;
  3. nella finestra del programma relativa alla licenza, ho inserito, più o meno, “questo programma è rilasciato con licenza GPL versione 3, ovvero potete scaricarlo, utilizzarlo e modificarlo come credete. È anche gratis. L’unica accortezza è che qualsiasi derivato di questo software deve a sua volta essere rilasciato con la stessa licenza, e senza rimuovere questo messaggio di copyright. Creato nel gennaio 2016 da Marco Motta per http://www.mathhelp.eu.”, seguito da un pulsante “Visualizza il testo completo della licenza” che rimanda alla pagina https://www.gnu.org/licenses/gpl-3.0.txt;
  4. Ogni file *.py inizia con (oscuro l’email)

[code]"""

This file is part of CalibrateTouchScreen

Copyright © 2016 - Marco Motta - www.mathhelp.eu

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation: you can use either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, see http://www.gnu.org/licenses/.

“”"[/code]

Mi sembra che vada bene così, o sbaglio?

Per quanto riguarda il campo Source0, a me funziona mettendo il tarball in ~/rpmbuild/SOURCES. Quando dici che devo mettere il percorso completo, intendi un link al web, ovvero qualcosa del tipo "Source0: http://miosito.it/tarball.tar.gz?

Mi pare vada benone.
Sì, nel source serve qualcosa di quel tipo…

Source: http://tuosito.it/downloads/%{name}-%{version}.tar.gz