Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

SPECS / SRPM et RPM pour timekpr

shnoulle

Bonjour,

Ayant besoin d'avoir timekpr sur Fedora, je me lance pour la construction du SPECS en vue du rpm.

J'ai 2 SPECS à disposition. Il existe un script d'installation dans timekpr.

Le SPEC pour OpenSuse utilise le script d'installation ou presque pour installer le logiciel
Le SPEC pour CaixaMagica (?) : http://people.caixamagica.pt/tmarques/Timekpr/current/SPECS/timekpr.spec

Le Spec reprend le script d'installation plutot à la main.

Pour la suppression, quel sera la meilleure solution ? Existe t'il une autre solution que de, au final, faire du cp/mkdir ?

Autre chose , concernant polkit : comment faire dans l'un des fichier source pour que le lanceur soit lancé en tant que admin ou root ?
Ma première idée est d'utiliser beesu dans le fichier desktop, mais j'ai vu dans d'autres SPECS l'utilisation de
%{_datadir}/polkit-1/actions/net.launchpad.INFODIVERSE.pkexec.OUTIL.policy (le SPECS de grub-customizer).

Par contre, je ne vois pas très bien comment intégrer cela dans les nouvelles sources pour Fedora ?

Voila pour la base ....

Merci,
Denis

Bigorre65

Bonjour,
La partie %install est un peu artisanale, certes. On pourrait utiliser la commande install plutôt que cp/mkdir.

Par contre, c'est les sections post et postun qui me font plus "peur" : normalement, on ne jardine plus dans les fichiers /etc/pam.d/* , on utilise plutôt authconfig. En plus les fichiers en question n'existent pas sur mon système... Le fichier à viser serait plutôt /etc/pam.d/system-auth-ac , mais je ne sais pas si les modifs survivront à un authconfig...

shnoulle

Bigorre65 wrote:Par contre, c'est les sections post et postun qui me font plus "peur" : normalement, on ne jardine plus dans les fichiers /etc/pam.d/* , on utilise plutôt authconfig. En plus les fichiers en question n'existent pas sur mon système... Le fichier à viser serait plutôt /etc/pam.d/system-auth-ac , mais je ne sais pas si les modifs survivront à un authconfig...

Salut,

J'ai trouvé des sources plus à jour ( 0.3.5) faite pour ArchLinux, je vais regarder ce qu'il en est.

Par contre : concernant les services. Je créé mon fichier timekpr.service dasn les sources. Comment ajouter et activer (sous condition de première installation) ce service ?

Pour l'activer sous condition, je suppose que cela sera un truc du genre:

...
BuildRequires:  systemd
....
Requires(post): systemd
Requires(preun): systemd
....
%post
....
#Init systemd
%systemd_post timekpr.service
if [ "$1" != "1" ]; then # Première installation ?
     # Enable timekpr.service
fi

...
%preun
%systemd_preun timekpr.service

On va continuer quoi 🙂

Bigorre65

http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Syntax : $1 = 1 correspond bien à une install et pas une update
du coup un

if [ "$1" != "1" ]
then
    systemctl enable timekpr.service
    systemctl  timekpr.service
fi

devrait le faire, après avoir installé timepkr.service dans /lib/systemd/system/

shnoulle

Bigorre65 wrote:Bonjour,
Par contre, c'est les sections post et postun qui me font plus "peur" : normalement, on ne jardine plus dans les fichiers /etc/pam.d/* , on utilise plutôt authconfig. En plus les fichiers en question n'existent pas sur mon système... Le fichier à viser serait plutôt /etc/pam.d/system-auth-ac , mais je ne sais pas si les modifs survivront à un authconfig...

Sur le site de feforaforum,

J'ai trouve gdm-password pour limiter par heure.
Mais je me demande si pour fedora, il ne vaudrait pas mieux ajouter les lignes ailleurs, j'ai regardé du coté de authconfig, voire pourquoi pas du coté de authconfig-gtk

Peut être à coup de inclure ?
Créer un fichier auth/pam.d/timekpr :

account required pam_time.so
account required pam_access.so

Et l'inclure dans authconfig-gtk uniquement.

A propos : ne serait il pas conseillé de :
- Créer le fichier postinst
- Indiquer que la configuration n'est pas complète sans postinst ?
- Parceque en fait : la partie postinst limite l'entrée, mais le daemon fonctionne sans (est cela aussi sur debian)

shnoulle

Voici donc le SPECS final, fonctionnel.

L'outil en lui même n'est plus maintenu, donc bon ...

========================
Name: timekpr
Version: 0.3.5~ppa1~14.04~ubuntu5
URL: http://code.launchpad.net/timekpr
Source0: https://launchpad.net/~mjasnik/+archive/ubuntu/ppa/+files/%{name}_%{version}.tar.gz

%description
This program will track and control the computer usage of
your user accounts. You can limit their daily usage based
on a timed access duration and configure periods of day
when they can or cannot log in.
.
Any bugs should be reported to our bug tracker:
https://bugs.launchpad.net/timekpr/+bugs
========================

Ce qui me géne le plus dans le SPECS:
- le chmod, j'ai juste réglé timekpr-client pour que son lancement ne bug pas. Cela permet d'avoir les notifications. Mais rpmlint se plain des droits : faut il les gérere à gros coups de chmod ?
- la dépendance avec beesu : mais c'est parcque je sais pas faire : une idée pour le lancement convenable via policy ?
- les 2 scripts .postinst / postrm : vaut il mieux les inclure directement au fichier SPECS ?
- Comme on n'utilise pas le setup.py , j'ai commenté les différents paramètre du specs python de base
- je n'ai pas compris le système des $lang

Les fichiers:
spec : http://www.shnoulle.net/timekpr-rpms/SPECS/timekpr.spec
src.rpm : http://www.shnoulle.net/timekpr-rpms/timekpr-0.3.5~ppa1~14.04~ubuntu5-6.fc20.src.rpm
rpm pour ceux qui en aurait envie : http://www.shnoulle.net/timekpr-rpms/timekpr-0.3.5~ppa1~14.04~ubuntu5-6.fc20.i686.rpm (SANS AUCUNE GARANTIE ( chémoissamarche))