Sébastien Gardé a écrit 6 commentaires

  • [^] # Re: Coaca

    Posté par  . En réponse à la dépêche Entretien avec Richard Stallman au sujet des DRMs. Évalué à 6.

    PS : c'est un autre débat, mais fumer ne tue pas, il ne fait que réduire l'espérance de vie.

    Comme une balle .... qui réduit l'espérance de vie à quelques nanosecondes ...

  • [^] # Re: Pour un débutant, plutôt Python

    Posté par  . En réponse au message Conseil pour créer un frontend. Évalué à 1.

    Bravo et merci pour la synthèse ... Python et GTK semble donc être un bon compromis.
    Je me lance ....

  • [^] # Re: Un langage de script + un toolkit graphique standard

    Posté par  . En réponse au message Conseil pour créer un frontend. Évalué à 1.

    Je vais lire avec attention ton article. En tout cas merci de ta réponse. J'étais en train de m'orienter vers Python en utilisant Tkinter comme expliquer sur Wikibook (http://fr.wikibooks.org/wiki/Programmation_Python_Introducti(...)
    Ta solution semble convenir à ce que je veux faire. Il se peut que je te sollicite dans les prochains jours :)
    Merci encore

  • # Erreur de segmentation vlc $STREAM

    Posté par  . En réponse au journal fricorder : magnetoscope pour flux freebox. Évalué à 1.

    Pour ma part j'ai téléchargé l'archive hier après midi .... La phase de configuration de l'enregistrement se passe sans problème mais lors de l'enregistrement j'ai le message suivant: 
    VLC media player 0.8.4-svn20040920 Janus
Warning: option --filter is deprecated. You should use --vout-filter instead.
[00000269] dummy interface: Using the dummy interface module...
./frecord.sh: line 76: 11523 Erreur de segmentation  vlc $STREAM --filter deinterlace:bob --sout "#std{access=file,mux=ts,url=$OUTFILE.mpg}" -I dummy
./frecord.sh: line 22: kill: (11523) - Aucun processus de ce type
./frecord.sh: line 71: 11531 Processus arrêté      sleep $LENGTH
./frecord.sh: line 60: 11528 Processus arrêté      zenity --display=:0.0 --progress --pulsate --title "FriCorder: Enregistrement de" --text `basename $OUTFILE`
    Alors si quelqu'un à une idée, ce serait cool ! En tout cas chapeau à Manatlan

  • [^] # Re: Et si

    Posté par  . En réponse au message Fetchmail problème de permission. Évalué à 2.

    J'ai finalement compris pourquoi à chaque redémarrage le propriétaire du fichier .fetchmailrc redevenait le user "fetchmail" et non "root" comme je le voulais. En fait dans le script de démarrage /etc/init.d/fetchmail il y avait cette ligne: 
    USER=fetchmail
    Je l'ai donc modifiée: 
    USER=root
    En conclusion, l'unique moyen que j'ai trouvé pour executer fetchmail en daemon automatiquement au démarrage sans utiliser la crontab est de modifier les lignes suivantes dans le script de démarrage /etc/init.d/fetchmail: 
    CONFFILE=/etc/.fetchmailrc
    USER=root
    Puis de mettre dans le fichier /etc/.fetchmailrc: 
    set daemon 600
    Où 600 est la période de scrutation en seconde. Je reste preneur d'une solution plus élégante, parceque bon ... on peut pas dire que c'est vraiment du haut vol, quand même !

  • [^] # Re: Et si

    Posté par  . En réponse au message Fetchmail problème de permission. Évalué à 2.

    Tout d'abord merci de ta réponse. Je viens de mettre le fichier .fetchmailrc dans /etc/.fetchmailrc et j'ai modifier le script de lancement. La modification a bien été prise en compte suite au redémarrage de fetchmail MAIS le fichier de log /var/log/mail.info continue de me dire: 
    [procmail]:Insufficient privileges to deliver to X
[fetchmail]:MDA returnet nonzero status 77
[fetchmail]:not flushed
    Apparemment c'est procmail qui est concerné, mais je n'ai pas trouvé d'où cela pourrait provenir. Pour info, le "forcage" du propriétaire du fichier /etc/.fetchmailrc à "root" débloque toujours la situation et je ne comprends toujours pas le mécanisme qui au redémarrage réattribue fetchmail comme étant le propriétaire de ce même fichier fetchmailrc. Merci encore .... Au pire, il me reste la solution crontab !