Il y a peu de logiciels Windows que j’envie sous mon environnement Linux. TortoiseSVN en fait parti. C’est une petit logiciel libre qui ajoute à votre menu contextuel (bouton droit) toute une série d’actions pour gérer vos dépôts SVN. Je viens heureusement de tomber sur le projet RabbitVCS qui apporte exactement les mêmes fonctionnalités sous Linux.
TortoiseSVN vs RabbitVCS
Aprés l’installation automatique, voici un nouveau script shell « maison » permettant de mettre simplement à jour votre serveur Nagios (core et plugins inclus).
Ce script est une synthése des articles « Comment mettre à jour son serveur Nagios ? » et « Mise à jour des plugins Nagios« . Il ne doit être utilisé que si vous avez installé Nagios à partir de cette procédure ou de ce script d’installation automatique.
Le script est distribué sous licence GPL. Libre à vous de le modifier pour l’adapter à vos besoins. Si des âmes charitables veulent modifier le script pour l’adapter à d’autres distribution GNU/Linux ou BSD, je suis preneur pour les mettre en téléchargement sur mon serveur.
On lance la commande suivante pour télécharger le script sur son serveur et le rendre exécutable:
cd /tmp wget --no-check-certificate https://raw.github.com/nicolargo/nagiosautoinstall/master/nagiosautoupdate.py chmod a+x nagiosautoupdate.py
PS: vous pouvez télécharger le script directement par l’URL suivante (GitHub).
Il suffit ensuite de lancer le script et de répondre aux questions posées par le système (en root ou précédé de la commande sudo):
./nagiosautoupdate.py
Le script archive la configuration n-1, il suffit donc d’ouvrir un terminal et de saisir les commandes suivantes pour revenir dans l’ancienne version (en root ou précédé de la commande sudo):
cd / tar zxvf /tmp/nagios-backup.tgz chown -R nagios:nagios /usr/local/nagios
Dans la version 0.9 du script la mise à jour se fera vers:
Nagios Core version 4.0.0 Nagios Plugins version 1.5 NRPE version 2.15
Vous voulez tester comment est vu votre site/blog sur un IPhone mais vous n’en avez pas un sous la main (ben ouep c’est pas libre alors…) ? Alors vous serez heureux d’apprendre qu’il existe une méthode assez simple pour que votre navigateur favori ( j’ai nommé Firefox) se fasse passer pour un IPhone…
La première chose à faire est d’installer le plugin « User Agent Switchers » qui va permettre à Firefox de se déguiser en IPhone. Une fois le plugin installé et le navigateur redémarré, un nouveau menu sous « Outils / Default User Agent » devrait apparaitre:
Il suffit de cliquer sur le bouton « IPhone 3.0 » pour que Firefox se fasse passer pour un navigateur IPhone. Pou revenir à un comportement normal de votre navigateur, il suffira de cliquer sur le bouton « Default User Agent ».
Rien de plus simple, il suffit de se rendre sur l’URL de votre blog pour le voir s’afficher comme sur un iPhone. Par exemple Le Blog de Nicolargo (c’est juste un exemple, j’utilise le plugin WordPress WPTouch donc l’affichage devrait être adapté…).
Les esprits chagrins vont me dire que cela n’est pas du tout représentatif car la résolution de l’Iphone est beaucoup plus faible que la résolution de notre écran, c’est vrai mais… il existe des sites (par exemple TestIphone) qui permettent d’effectuer le même test mais dans une frame simulant la taille d’un IPhone. Perso le test chez moi du site TestIphone n’est pas concluant car je suis redirigé vers la version plein écran de mon blog…
Bugzilla et un outil de suivi de bug (bug tracking system) permettant à une communauté d’utilisateur de logger, suivre et traité les bugs d’un système/logiciel. Bugzilla est utilisé pour le suivi de nombreux logiciels libre: Mozilla, Kernel Linux, Gnome, KDE, Apache, Open Office, Eclipse…
Il y a plusieurs méthodes pour installer Nagios, le système de supervision libre, sur un nouveau serveur. La plus simple est d’utiliser les dépôts officiels de votre distribution GNU/Linux, avec le désavantage de ne pas avoir les dernières versions disponibles. La seconde est de suivre pas à pas mon tutoriel (PART 1 et 2) qui permet de faire une compilation depuis les sources.
Je vous propose dans ce billet une troisième voie, qui mixe la simplicité de la première méthode et la finesse de la seconde.
J’ai développé un petit script (sous licence GPL) permettant d’automatiser l’installation d’un serveur Nagios complet sur une distribution GNU/Linux Ubuntu (j’ai validé le script sur Ubuntu Desktop et Ubuntu Server). Libre à vous de modifier ce script pour l’adapter à vos besoins. Si des âmes charitables veulent modifier le script pour l’adapter à d’autres distribution GNU/Linux ou BSD, je suis preneur pour les mettre en téléchargement sur mon SVN.
On lance la commande suivante pour télécharger le script sur son serveur et le rendre exécutable:
wget --no-check-certificate https://raw.github.com/nicolargo/nagiosautoinstall/master/nagiosautoinstall-ubuntu.sh chmod a+x nagiosautoinstall-ubuntu.sh
PS: vous pouvez télécharger le script directement sur GitHub.
Il suffit ensuite de lancer le script et de répondre aux questions posées par le système (en root ou précédé de la commande sudo):
./nagiosautoinstall-ubuntu.sh
Dans la version 0.8 du script la configuration finale est la suivante:
Nagios Core version 4.0.0 Nagios Plugins version 1.5 Utilisateur système: nagios Groupe système: nagios Utilisateur pour l'interface Web (http://localhost/nagios/): nagiosadmin
La dernière version de WordPress vient de sortir. Elle apporte son lot d’améliorations et de nouvelles fonctionnalités (voir la liste exhaustive ici). Voici la procédure, de plus en plus simple, pour mettre à jour votre blog d’une version 2.8.x vers 2.9.
On commence bien sûr par sauvegarder l’ensemble du blog (contenue ET base de donnée), on ne sait jamais…
J’utilise, depuis la version 2.7 de WordPress, la procédure de mise à jour automatique, il suffit de se rendre dans le menu « Tools / Upgrade » et de cliquer sur le lien « Upgrade to WordPress 2.9 » et le tour est joué:
Il y a quelques temps, j’avais développé un logiciel en ligne de commande permettant de tester les caractéristiques de débit, délais et gigue entre deux points d’un réseau: SJitter. Afin d’en simplifier l’installation sous GNU/Linux Ubuntu, j’ai créer un dépôt PPA.
Ainsi, l’installation de SJitter ce résume aux lignes de commandes suivantes:
sudo add-apt-repository ppa:nicolashennion/ppa
sudo aptitude update
sudo aptitude install sjitter
et voilà le travail:
sjitters -h
usage: sjitters [-i] [-p PORT]
-p PORT: where PORT is the port number (>1024, <65535) [default:9930]
-i : Verbose mode
sjitterc -h
usage: sjitterc -c SERVER [[-n NBPCKT] | [-t SECOND]] [-p PORTNB] [-w SIZE] [-b BITRAT] [-s TOS]
-c SERVER: where SERVER is the server IP address or name
-n NBPCKT: where NCPCKT is the number of datagram (>1 , <65535) [default:100]
-t SECOND: where SECOND is the number of second (>1) [default:10]
-p PORTNB: where PORTNB is the port number (>1024, <65535) [default:9930]
-w SIZE: where SIZE is the application buffer size (bytes) (>128, <8000) [default:1400]
-b BITRATE: where BITRATE is the bitrate (IP level) in Kbps (>10) [default:100]
-s TOS: where TOS is the hexadecimal value for IP header TOS field (>=0x00, <=0xFF) [default:0]
Vous développez une application sous licence libre et vous souhaitez donc mettre les sources à disposition des Internautes sans pour autant être dépendant d’un fournisseur de service comme SourceForge ? Alors ce billet est fait pour vous…
Nous allons détailler l’installation d’un serveur de développement basée sur des logiciels libres:
Allez zou, on entre directement dans le vif du sujet…
Peut importe l’OS, il faut juste que vous soyer à l’aise avec lui. Donc n’importe quel OS GNU/Linux, BSD ou Unix fera l’affaire (si tu demandes et Windows ? tu cliques sur le bouton Démarrer / Arrêter l’ordinateur et tu installes un vrai OS).
Personnellement, j’utilise pour illustrer ce billet une Ubuntu Serveur 8.04, l’installation se fera via le compte root et le nom de ma machine est dev.mondomaine.com.
Pour être sûr que votre serveur Ubuntu est à jour:
aptitude update
aptitude safe-upgrade
Tout commence par l’installation d’Apach et de son module SVN:
aptitude install apache2 libapache2-svn
Puis on désactive les sites par défaut (le fameux « It works! »):
sudo a2dissite default
/etc/init.d/apache2 reload
A ce stade, le serveur devrait vous renvoyer un message comme quoi aucun serveur virtuel n’est configuré (« [warn] NameVirtualHost *:80 has no VirtualHosts »).
Nous allons donc créer le serveur virtuel du projet (libre à vous d’en créer autant que de besoins):
# vi /etc/apache2/sites-available/dev.mondomaine.com
<virtualHost *:80>
ServerName dev.mondomaine.com
ServerAdmin admin@mondomaine.com
DocumentRoot /var/www/dev/
ErrorLog /var/log/apache2/error.log
<Directory />
Options FollowSymLinks
AllowOverride All
</Directory>
</virtualHost>
On active le serveur virtuel dans la configuration d’Apache:
mkdir /var/www/dev
a2ensite dev.mondomaine.com
/etc/init.d/apache2 reload
On teste l’installation:
echo « OK » > /var/www/dev/index.html
Puis on ouvre un navigateur à l’URL: http://dev.mondomaine.com/
On installe Subversion en suivant la procédure suivante (le projet sera donc stocké dans le répertoire /var/svn/projet, à modifier selon votre bon vouloir…).
On configure Apache pour qu’il puisse lire ce dépôt:
# vi /etc/apache2/mods-available/dav_svn.conf
<Location /svn>
DAV svn
SVNParentPath /var/svn
SVNListParentPath On
AuthType Basic
AuthName « Ubik Subversion Repository »
AuthUserFile /etc/apache2/dav_svn.passwd
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
On créé un utilisateur privilégié qui aura les droits de commit sur le dépôt:
htpasswd –cs /etc/apache2/dav_svn.passwd nicolargo
Attention les prochain utilisateurs devront être créés avec la commande:
htpasswd -s /etc/apache2/dav_svn.passwd titi
Puis on redémarre le serveur:
sudo /etc/init.d/apache2 restart
Il est possible de tester l’installation en entrant l’URL suivante dans votre navigateur Web: http://dev.mondomaine.com/svn/projet/
La liste des dépôt devrait apparaitre.
Le dépôt SVN de votre projet est donc maintenant accessible via l’adresse: http://dev.mondomaine.com/svn/projet/
Lors d’un commit, un couple login/password sera demandé automatiquement (il faudra saisir les informations d’un utilisateur privilégié).
On installe Trac:
aptitude install libapache2-mod-python trac python-pygments enscript
sudo a2enmod mod_python
On ajoute la configuration suivante dans le fichier /etc/apache2/sites-available/dev.mondomaine.com (dans la balise VirtualHost):
<Location /trac>
SetHandler mod_python
PythonInterpreter main_interpreter
PythonHandler trac.web.modpython_frontend
PythonOption TracEnvParentDir /var/www/dev/trac
PythonOption TracUriRoot /trac
PythonOption PYTHON_EGG_CACHE /tmp
</Location>
<LocationMatch « /trac/[[:alnum:]]+/login »>
AuthType Basic
AuthName « Trac Dev server »
AuthUserFile /etc/apache2/dav_svn.passwd
Require valid-user
</LocationMatch>
trac-admin /var/www/dev/trac/projet initenv
chown -R www-data:www-data /var/www/dev/trac/
Sources m’ayant aidées lors de la rédaction de ce billet:
Sous l’impulsion de la multiplication des projets open-source, la gestion en configuration de vos sources est devenue une brique essentielle dans le développement de logiciels informatiques. Nous allons dans ce billet parler de GIT (développé par Mr Linus Torvalds en personne) qui contrairement à CVS ou SVN se base sur une architecture décentralisée.
Pour illustrer ce tutoriel, nous allons utiliser l’architecture suivante:
A: Dépôt GIT
B: Dépôt GIT (copie de A)
C: Dépôt SVN
On installe GIT:
# sudo aptitude install git-core git-svn
puis on le configure:
# git config –global user.name « Nicolas Hennion »
# git config –global user.email « contact_at_nicolargo_._com »
Projet dont les sources sont stockées dans le répertoire ~/workspace/projet.
# cd ~/workspace/projet
# ls -alF
total 92
-rw-r—– 1 nicolargo nicolargo 158 Jan 28 15:45 001-display-ogg-theora-file.sh
-rw-r—– 1 nicolargo nicolargo 89 Jan 28 15:49 002-display-webcam.sh
-rw-r—– 1 nicolargo nicolargo 242 Feb 2 17:02 003-display-webcam-320×200.sh
-rw-r—– 1 nicolargo nicolargo 153 Jan 28 16:55 004-display-effect-webcam.sh
-rw-r—– 1 nicolargo nicolargo 157 Jan 28 17:16 005-display-textoverlay-webcam.sh
-rw-r—– 1 nicolargo nicolargo 89 Feb 2 15:49 006-streaming-udp-client-theora.sh
-rw-r—– 1 nicolargo nicolargo 579 Feb 2 15:50 006-streaming-udp-server-theora.sh
-rw-r—– 1 nicolargo nicolargo 224 Jan 30 14:46 007-streaming-to-icecast.sh
-rw-r—– 1 nicolargo nicolargo 116 Feb 2 15:40 008-streaming-tcp-client-theora.sh
-rw-r—– 1 nicolargo nicolargo 266 Feb 2 15:45 008-streaming-tcp-server-theora.sh
-rw-r—– 1 nicolargo nicolargo 4192 Feb 3 11:56 009-streaming-rtp-client-theora.sh
-rw-r—– 1 nicolargo nicolargo 622 Feb 3 11:52 009-streaming-rtp-server-theora.sh
-rw-r—– 1 nicolargo nicolargo 194 Feb 3 12:26 010-VLC.sdp
-rw-r—– 1 nicolargo nicolargo 534 Feb 3 12:15 010-streaming-rtp-client-x264.sh
-rw-r—– 1 nicolargo nicolargo 706 Feb 3 12:35 010-streaming-rtp-server-x264.sh
-rw-r—– 1 nicolargo nicolargo 1072 Feb 3 15:16 011-streaming-rtp-client-x264-speex.sh
-rw-r—– 1 nicolargo nicolargo 883 Feb 3 14:57 011-streaming-rtp-server-x264-speex.sh
-rw-r—– 1 nicolargo nicolargo 1041 Feb 3 15:13 012-streaming-rtp-client-x264-pcma.sh
-rw-r—– 1 nicolargo nicolargo 880 Feb 3 15:11 012-streaming-rtp-server-x264-pcma.sh
-rw-r—– 1 nicolargo nicolargo 1720 Feb 2 16:21 GStreamer – RTP client-server.txt
-rw-r—– 1 nicolargo nicolargo 1020 Feb 3 15:31 client.sh
-rw-r—– 1 nicolargo nicolargo 883 Feb 3 15:28 server.sh
On initialise le dépôt GIT:
# git init
Initialized empty Git repository in .git/
Puis on ajoute l’ensemble des fichiers sources à ce dépôt GIT:
# git add *
On vérifie que la commande précédente à bien été prise en compte
# git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use « git rm –cached <file>… » to unstage)
#
# new file: 001-display-ogg-theora-file.sh
# new file: 002-display-webcam.sh
# new file: 003-display-webcam-320×200.sh
# new file: 004-display-effect-webcam.sh
# new file: 005-display-textoverlay-webcam.sh
# new file: 006-streaming-udp-client-theora.sh
# new file: 006-streaming-udp-server-theora.sh
# new file: 007-streaming-to-icecast.sh
# new file: 008-streaming-tcp-client-theora.sh
# new file: 008-streaming-tcp-server-theora.sh
# new file: 009-streaming-rtp-client-theora.sh
# new file: 009-streaming-rtp-server-theora.sh
# new file: 010-VLC.sdp
# new file: 010-streaming-rtp-client-x264.sh
# new file: 010-streaming-rtp-server-x264.sh
# new file: 011-streaming-rtp-client-x264-speex.sh
# new file: 011-streaming-rtp-server-x264-speex.sh
# new file: 012-streaming-rtp-client-x264-pcma.sh
# new file: 012-streaming-rtp-server-x264-pcma.sh
# new file: GStreamer – RTP client-server.txt
# new file: client.sh
# new file: server.sh
#
Enfin on valide (commit) le dépôt:
# git commit -m « Premier commit »
Created initial commit 6a4ff29: Premier commit
22 files changed, 183 insertions(+), 0 deletions(-)
create mode 100644 001-display-ogg-theora-file.sh
create mode 100644 002-display-webcam.sh
create mode 100644 003-display-webcam-320×200.sh
create mode 100644 004-display-effect-webcam.sh
create mode 100644 005-display-textoverlay-webcam.sh
create mode 100644 006-streaming-udp-client-theora.sh
create mode 100644 006-streaming-udp-server-theora.sh
create mode 100644 007-streaming-to-icecast.sh
create mode 100644 008-streaming-tcp-client-theora.sh
create mode 100644 008-streaming-tcp-server-theora.sh
create mode 100644 009-streaming-rtp-client-theora.sh
create mode 100644 009-streaming-rtp-server-theora.sh
create mode 100644 010-VLC.sdp
create mode 100644 010-streaming-rtp-client-x264.sh
create mode 100644 010-streaming-rtp-server-x264.sh
create mode 100644 011-streaming-rtp-client-x264-speex.sh
create mode 100644 011-streaming-rtp-server-x264-speex.sh
create mode 100644 012-streaming-rtp-client-x264-pcma.sh
create mode 100644 012-streaming-rtp-server-x264-pcma.sh
create mode 100644 GStreamer – RTP client-server.txt
create mode 100644 client.sh
create mode 100644 server.sh
Nous allons utiliser la commande GIT « clone » permettant de faire une copie locale (dépôt local de la machine B) de son dépôt distant (machine A). C’est sur cette copie que nous allons ensuite travailler. On peut noter que j’utilise le protocole SSH pour récupérer les sources de la machine A, mais il est également possible d’utiliser le protocole « git » ou « http ».
# git clone ssh://nicolargo@B/~/workspace/gstpipelinearea
Nous allons maintenant créer sur notre machine B une nouvelle version de nos sources (une branche). Pour voir la liste des branches on utilise la commande suivante:
# git branch
* master
Comme on peut le voir il existe une seule branche (master) dans notre dépôt. Nous allons en créer une nouvelle avec la commande suivante:
# git branch version-2.0 master
On vient de créer une nouvelle version de notre projet nommé version-2.0 à partir de la branche principale (master). Il est ainsi possible de travailler sur cette version-2.0 sans impacter la version principale.
# git branch
* master
version-2.0
L’* à coté de master précise que pour l’instant toutes les actions GIT seront faites sur la branche master. Pour travailler sur la branche version-2.0, il faut sasir la commande:
# git checkout version-2.0
Switched to branch « version-2.0 »
On vérifie:
# git branch
master
* version-2.0
Si vous voulez fusionner (merge) la
version-2.0 à la branche principale (c’est à dire appliquer les
modifications faites dans la version-2.0 dans vos sources initiales),
il faut:
# git checkout master
# git merge version-2.0
Nous allons voir quelques exemples de manipulations de nos sources, je vous conseille fortement la lecture de la documentation (RFM…)
Pour ajouter un nouveau fichier à notre dépôt local, on commence par créer le fichier en question:
# echo « Quelques exemples de pipelines GStreamer » >> README
Puis on l’ajoute et on met à jour notre dépôt local:
# git add README
# git commit -a -m « Ajout du fichier README »
Created commit 1072258: Ajout du fichier README
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 README
On modifie le fichier source en question:
# echo « Merci d’ajouter une ligne de description par pipeline » >> README
On peut voir les différences entre notre dépôt actuel et le dépôt local en tapant la commande:
# git diff
diff –git a/README b/README
index 3040f44..a58b06d 100644
— a/README
+++ b/README
@@ -1 +1,2 @@
Quelques exemples de pipelines GStreamer
+Merci d’ajouter une ligne de description par pipeline
Puis on valide nos modifications dans le dépôt local:
# git commit -a -m « Modification fichier README »
Created commit f3c0c49: Modification fichier README
1 files changed, 1 insertions(+), 0 deletions(-)
En cas d’erreur il est possible de revenir facilement à une dernière version:
# git log
commit f3c0c49bfc181d9353d8536c49af55eb24a9318c
Author: Nicolas Hennion <contact@nicolargo.com>
Date: Wed Jul 8 17:11:03 2009 +0200Modification fichier README
commit 1072258108f25865e1965deeff7e651e29fb8f75
Author: Labo <labo@linux-demo-laptop.(none)>
Date: Wed Jul 8 16:56:56 2009 +0200Ajout du fichier README
commit 6a4ff298714032e8263f9425b50a86dcf8aa5888
Author: Nicolas Hennion <contact@nicolargo.com>
Date: Wed Jul 8 16:43:30 2009 +0200Premier commit
Par exemple pour revenir à notre première version du fichier README:
# git revert 1072258108f25865e1965deeff7e651e29fb8f75
On supprime le/les fichiers sources en question:
# git rm client.sh
# git rm server.sh
Puis on valide:
# git commit -a -m « Supression des fichers de test »
Created commit dc78e6c: Supression des fichers de test
2 files changed, 0 insertions(+), 32 deletions(-)
delete mode 100644 client.sh
delete mode 100644 server.sh
Nous avons fait quelques manipulation sur notre dépôt local (machine B). Maintenant nous souhaitons proposer ces modifications au dépôt distant (machine A). Pour cela, nous allons dans un premier temps pousser les modifications de B vers A:
# git push
Counting objects: 9, done.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (8/8), 861 bytes, done.
Total 8 (delta 3), reused 0 (delta 0)
To ssh://nicolargo@B/~/workspace/gstpipelinearea
6a4ff29..dc78e6c master -> master
Par défaut, le push se fait sur la brance principale (master), pour spécifier le push d’une autre version, il faut la spécifier dans la ligne de commande (« git push version-2.0 » par exemple).
Si on fait a ce moment là un ls dans le répertoire du dépôt de la machine A, les modifications n’apparaissent pas (le fichier README est inexistant et les fichier client.sh et server.sh sont présents).
# ls -alF
-rw-r—– 1 nicolargo nicolargo 158 Jan 28 15:45 001-display-ogg-theora-file.sh
-rw-r—– 1 nicolargo nicolargo 89 Jan 28 15:49 002-display-webcam.sh
-rw-r—– 1 nicolargo nicolargo 242 Feb 2 17:02 003-display-webcam-320×200.sh
-rw-r—– 1 nicolargo nicolargo 153 Jan 28 16:55 004-display-effect-webcam.sh
-rw-r—– 1 nicolargo nicolargo 157 Jan 28 17:16 005-display-textoverlay-webcam.sh
-rw-r—– 1 nicolargo nicolargo 89 Feb 2 15:49 006-streaming-udp-client-theora.sh
-rw-r—– 1 nicolargo nicolargo 579 Feb 2 15:50 006-streaming-udp-server-theora.sh
-rw-r—– 1 nicolargo nicolargo 224 Jan 30 14:46 007-streaming-to-icecast.sh
-rw-r—– 1 nicolargo nicolargo 116 Feb 2 15:40 008-streaming-tcp-client-theora.sh
-rw-r—– 1 nicolargo nicolargo 266 Feb 2 15:45 008-streaming-tcp-server-theora.sh
-rw-r—– 1 nicolargo nicolargo 4192 Feb 3 11:56 009-streaming-rtp-client-theora.sh
-rw-r—– 1 nicolargo nicolargo 622 Feb 3 11:52 009-streaming-rtp-server-theora.sh
-rw-r—– 1 nicolargo nicolargo 194 Feb 3 12:26 010-VLC.sdp
-rw-r—– 1 nicolargo nicolargo 534 Feb 3 12:15 010-streaming-rtp-client-x264.sh
-rw-r—– 1 nicolargo nicolargo 706 Feb 3 12:35 010-streaming-rtp-server-x264.sh
-rw-r—– 1 nicolargo nicolargo 1072 Feb 3 15:16 011-streaming-rtp-client-x264-speex.sh
-rw-r—– 1 nicolargo nicolargo 883 Feb 3 14:57 011-streaming-rtp-server-x264-speex.sh
-rw-r—– 1 nicolargo nicolargo 1041 Feb 3 15:13 012-streaming-rtp-client-x264-pcma.sh
-rw-r—– 1 nicolargo nicolargo 880 Feb 3 15:11 012-streaming-rtp-server-x264-pcma.sh
-rw-r—– 1 nicolargo nicolargo 1720 Feb 2 16:21 GStreamer – RTP client-server.txt
-rw-r—– 1 nicolargo nicolargo 1020 Feb 3 15:31 client.sh
-rw-r—– 1 nicolargo nicolargo 883 Feb 3 15:28 server.sh
Pour consolider les sources sur la machine A, il faut utiliser la commande suivante:
# git reset –hard
HEAD is now at dc78e6c… Suppression des fichers de test
Pas de problème, GIT dispose d’un bundle permettant de récupérer et de committer vers un serveur SVN.
Pour récupérer les sources d’un serveur SVN C:
# git svn clone svn://nicolargo@C/svn/gstpipelinearea
On utilise les commandes classique pour gérer son dépôt GIT (voir les chapitres précédant).
Pour commiter les modifications sur le serveur SVN C:
# git svn rebase
# git svn dcommit
Vous pouvez suivre ce tuto pour configurer votre Eclipse pour utiliser un dépôts GIT.
Si comme moi, vous utilisez le plugin Adsense-deluxe pour gérer les espaces publicitaires de votre blog, vous avez eu la désagréable surprise de tomber sur le message suivant suite à une migration de votre blog vers la version 2.8.1 (ou supérieure) de WordPress:
Cela vient d’un problème de développement de certains plugins (dont Adsense-deluxe qui ne semble plus maintenu par son éditeur). Pour résoudre le problème et refaire fonctionner ce trsè bon plugin avec les dernières versions de WordPress, il suffit changer une ligne de code dans le plugin (remplacer l’appel de la fonction admin_head par admin_menu). Pour vous simplifier la tache, j’ai modifié le plugin pour vous, il ne vous reste plus qu’a télécharger la version compatible du plugin ici (fichier ZIP à dézipper dans le sous répertoire plugin de votre blog WordPress):
PS: votre configuration ne sera pas effacée 😉