[F15] Ajouter un raccourci personnalisé sous gnome 3

Comme vous le savez, gnome3 est assez .. épuré … en terme de paramétrage rapide. Et pour cause, le mot d’ordre semble avoir été de privilégier l’usage au paramétrage (ce qui ma foi est plutôt une bonne chose).

Du coup, voilà une manière propre d’ajouter un raccourci personnalisé dans la liste des applications favorites.

Pour cela il faut ajouter un nouveau fichier .desktop dans le dossier share/applications, cependant contrairement à ce que certains conseillent, je suis totalement opposé à l’écriture dans le dossier /usr/share/aplications, et pour cause, chaque utilisateur dispose de son propre dossier : ~/.local/share/applications (à créer s’il n’existe pas encore).

Par exemple, pour ajouter un lien vers eclipse avec les arguments qui vont bien :

mkdir -p ~/.local/share/applications
cp /usr/share/applications/eclipse.desktop ~/.local/share/applications

Puis modifier le fichier eclipse.desktop comme bon vous semble :

[Desktop Entry]
Type=Application
Name=Eclipse superstack
Comment=Eclipse Integrated Development Environment
Icon=eclipse
Exec=eclipse -vmargs -Xms1024m -Xmx4196m
Terminal=false
Categories=Development;IDE;Java;

Ensuite il suffit de réactualiser la liste des applications, pour cela on redémarre gnome3 :
[alt] + [F2], tapez « r » puis [enter]

Et voilà votre nouveau raccourci « eclipse superstack » est ajouté à la liste des applications disponibles.

Gnome3 : quelques astuces

Je viens de me mettre à gnome3, j’en bave un peu pour retrouver mes marques.

Du coup je vais poster ici ce qui m’a vraiment bloqué pour l’instant :

Afficher la date de l’horloge : gsettings set org.gnome.shell.clock show-date true
Afficher les numéros de semaine dans le calendrier : gsettings set org.gnome.shell.calendar show-weekdate true
Ajouter les boutons minimize et maximize des fenêtres : gconftool-2 –set /desktop/gnome/shell/windows/button_layout –type string « :minimize,maximize,close »

Utiliser la touche [Del] pour supprimer dans nautilus :

1) Activer le mode de modification des raccourcis : gsettings set org.gnome.desktop.interface can-change-accels true

2) Puis aller dans Fichier > edition > Mettre à la poubelle (sans cliquer) et faire [Del] [Del] , le raccourci est modifié.

3) Désactiver le mode : gsettings set org.gnome.desktop.interface can-change-accels false

et dans le même genre : https://bodman.wordpress.com/2011/08/01/ajouter-un-rac…se-sous-gnome3/

Voilà, c’est tout pour l’instant.

Sources : http://www.khattam.info/howto-add-minimize-maximizerestore-buttons-in-gnome-3-2011-05-26.html, http://www.khattam.info/howto-enable-delete-key-in-nautilus-3-fedora-15-2011-06-01.html

Valgrind with C++ on fedora 14

Si vous aussi, vous aviez une erreur lors de l’utilisation de valgrind avec fedora 14 en C++, réjouissez vous, la solution existe (et elle est  bien simple).

en root :
>yum reinstall libstdc++ libstdc++-devel gcc-c++ gcc
>ldconfig

Cela dit, j’ai observé un problème assez gênant, je dois refaire la manip après chaque reboot de la machine….

Ayant lu en diagonale le lien suivant, je n’ai pas encore obtenu solution finale, mais c’est déjà bien.

source: https://bugzilla.redhat.com/show_bug.cgi?id=650149

Faire ses propres RPMs sous Fedora

Bonjour à tous,
Cela fait bien longtemps que je voulais faire ce ticket. A chaque fois que j’ai une manipulation à faire sur un RPM c’est la même rengaine, c’est une action rare et du coup je dois bien passer deux heures à chercher pour faire une action qui devrait prendre 3 minutes.

Les RPM, et le packaging en général sont des sujets très intéressants, très documentés aussi. Je citerais mes sources en fin d’article.

Étape 1 – Préparation logiciel

Alors voici un certains nombre d’applications à installer pour être bien préparé :

(En root)
yum groupinstall "Fedora Packager"
yum install rpmdevtools
yum groupinstall "Development Tools"
yum install kernel-devel kernel-headers kmodtool fedpkg (pour les amoureux du noyau et des modules)

Etape 2 – Utilisateur builder

Bon je l’appel builder (je sors ça d’un tutos) mais prenez le nom que vous voulez.

(En root)
useradd builder
passwd builder
su - builder
rpmdev-setuptree

echo "%vendor                    VOTRE_NOM" >>    $HOME/.rpmmacros
echo "%packager             Fedora user" >>    $HOME/.rpmmacros
echo "%dist                       .f14" >>    $HOME/.rpmmacros

(Pensez bien sur à remplacer VOTRE_NOM et f14 pour les valeurs de votre choix)

Etape 2bis (facultative) – Préparation des signatures GPG

A la suite de l’étape 2, faites :

gpg --gen-key
echo "%_signature             gpg" >>    $HOME/.rpmmacros
echo "%_gpg_name              VOTRE_NOM" >>    $HOME/.rpmmacros
echo "%_gpg_path              /home/builder/.gnupg" >>    $HOME/.rpmmacros
gpg --export --armor >RPM-GPG-KEY-VOTRE_NOM

Etape 3 – Construction d’un RPM

Alors ici, plusieurs possibilités, voici donc une liste de quelques opérations courantes :

  • Construction d’un paquet déjà existant sur un dépôt distant
  • Construction d’un paquet à partir d’un src.rpm
  • Construction d’un paquet à partir du fichier SPEC

Construction d’un paquet déjà existant sur un dépôt distant

C’est le cas le plus simple et le plus courant. Par exemple, mettons qu’il y ait une erreur de dépendance entre deux paquets suite à la mise à jour de l’un sans recompilation de l’autre, la solution est de compiler à nouveau le paquet défectueux.

Parfois cette erreur n’est corrigée sur les serveurs que plusieurs jours après. Un solution serait alors de les devancer sans pour autant avoir à compiler à la main le dernier tar.gz qui traine.

Pour cela, rien de plus simple,  il suffit de récupérer le fichier src.rpm sur le dépôt distant directement avec yum :

(En builder)
cd ~/rpmbuild/SRPMS
yumdownloader --source mpd

Désormais le fichier src.rpm se trouve dans le dossier courant (~/rpmbuild/SRPMS) lisez la suite pour préparer le rpm.

Construction d’un paquet à partir d’un src.rpm

Une fois le fichier src.rpm copié dans le dossier rpmbuild/SRPMS de l’utilisateur builder :

(En builder)
rpmbuild --rebuild mpd-0.15.11-1.fc14.src.rpm

Et voila, le dossier rpmbuild/RPMS/x86_64 (ou i586, selon l’architecture de la machine local) contient le rpm désiré.

Si vous souhaitez préciser l’architecture ciblée, faite ainsi :

rpmbuild --rebuild mpd-0.15.11-1.fc14.src.rpm --target i586,x86_64

Si vous souhaitez pouvoir modifier ce paquet (ajouter un patch ou je ne sais quoi, lisez la suite).

Construction d’un paquet à partir du fichier SPEC

La préparation de paquet à partir d’un fichier SPEC est très fréquente aussi. Qu’il s’agisse d’une nouvelle application (donc absente des dépôts distants) ou bien d’une mise à jour. C’est le moyen de modifier des paquets déjà existants.

Pour ce faire, vos sources (le tar.gz ainsi que les patchs)  doivent être présentes dans le dossier ~/rpmbuild/SOURCES et votre fichier spec dans le dossier rpmbuild/SPECS.

Si vous disposez d’un src.rpm, utilisez la commande suivante :

(En builder)
rpm -ivh mpd-0.15.11-1.fc14.src.rpm

Si vous ne disposez que d’un fichier SPEC, il existe une commande qui, si les liens du spec sont corrects, vous permettra de rapatrier tous  les fichiers nécessaires.

(En builder)
cd ~/rpmbuild/SOURCES
spectool -g ../mpd.spec

Ensuite la construction se fait ainsi :

(En builder)
cd ~/rpmbuild/SPECS
rpmbuild -ba mpd.spec

A la fin de ces étapes, vous disposez enfin de rpm valides dans le dossier ~/rpmbuild/RPMS.

Pour les installer, une solution simple s’offre à vous :

(En root)
rpm -ivh  /home/builder/rpmbuild/RPMS/i386/mpd-0.15.11-1.fc14.i386.rpm

Mais une deuxième solution existe, le dépôt local.

REMARQUE : La compilation d’un RPM nécessite les dépendances de ce dernier. Pour les installer facilement :

yum-builddep less-394-1.fc4.src.rpm -y

 

Création d’un dépôt local pour yum

Préparation

Pour construire son propre dépôt il faut commencer par ranger les rpms dans un dossier commun. Ici j’utiliserais /DATA/depot/14.

On respectera l’arbo (RPM et SRPMS) déjà utilisée pour le dossier rpmbuild de l’utilisateur builder.

[FACULTATIF] Signer les paquets (avec builder)  rpmsign –addsign paquet.rpm [FACULTATIF]

Pour générer le dépôt, rien de plus simple :

(utilisateur gérant le dossier /DATA/depot/14)
cd /DATA/depot/14
createrepo .

Un dossier repodata est créé, tout s’est bien passé.

Définition du dépôt local dans yum

La définition du dépôt local se fait dans le dossier /etc/yum.repos.d/

Ajoutez-y un fichier local.repo contant les lignes suivantes :

[localrepo]
name=Fedora Core $releasever - My Local Repo
baseurl=file:///DATA/14
enabled=1
gpgcheck=0

mettez gpgcheck=1 si vos paquet sont signez, mais pensez alors à installer la clef GPG :

(En root)
rpm --import ~builder/RPM-GPG-KEY-VOTRENOM

A chaque modification du dépôt, pensez à refaire la commande createrepo. De même, pour vous assurer que ces nouveaux paquets soient pris en compte par yum, pensez a faire un yum clean metadata.

Voilà, c’est tout pour aujourd’hui.

Sources :

http://doc.fedora-fr.org/wiki/RPM_:_environnement_de_construction (mon ticket est très inspiré de cette page)

http://www.g-loaded.eu/2005/12/11/local-yum-repository/ (Partie dépôt local)

VMWare Server 2.0 on Fedora 10

Quelques notes à l’attention des futurs usagers :

  • Ne pas utiliser le rpm, préférer le tgz.
<u><b>Il s'agit d'une rustine à ne pas faire sur une machine en production.</b></u><br /><br />

[F10] Petite astuce avec les RPM

Lorsque l’on récupère un RPM exotique souvent on cherche à l’installer comme ça :

[root@localhost toky]# rpm -ivh *.rpm
erreur: Dépendances requises:
libgdk-1.2.so.0 est nécessaire pour coriolis-crlcore-1.0.20080221-1.i386
libgtk-1.2.so.0 est nécessaire pour coriolis-crlcore-1.0.20080221-1.i386
libgdk-1.2.so.0 est nécessaire pour coriolis-cyclop-1.0.20080221-1.i386
libgtk-1.2.so.0 est nécessaire pour coriolis-cyclop-1.0.20080221-1.i386
libgdk-1.2.so.0 est nécessaire pour coriolis-isobar-1.1.20080221-1.i386
libgtk-1.2.so.0 est nécessaire pour coriolis-isobar-1.1.20080221-1.i386
libgdk-1.2.so.0 est nécessaire pour coriolis-mistral-1.1.20080221-1.i386
libgtk-1.2.so.0 est nécessaire pour coriolis-mistral-1.1.20080221-1.i386
libgdk-1.2.so.0 est nécessaire pour coriolis-nimbus-1.1.20080221-1.i386
libgtk-1.2.so.0 est nécessaire pour coriolis-nimbus-1.1.20080221-1.i386

Et là on passe un certain temps à installer les dépendances lorsqu’il y en a beaucoup.

Mais il y a mieux !!

[root@localhost toky]# yum localinstall *.rpm
***********
***********
***********
–> Résolution des dépendances terminée
***********
***********
Le paquetage coriolis-nimbus-debuginfo-1.1.20080221-1.i386.rpm n’est pas signé

Presque bon …

[root@localhost toky]# yum –nogpgcheck localinstall *.rpm

Tada !!

Warcraft III : Battle.Net sous Linux Ou comment patcher WIne

Autrefois j’étais joueur linuxien sur Cedega, je n’avais jamais eu de problème avec Warcraft III. Le projet Cedega tombant dans l’oubli j’ai décidé de passer vers Wine.
Tout s’est très bien passé (Installation / Patch et mise à jour). Tout sauf le jeu sous Battle.Net (chat en ligne impossible et impossible d’héberger une partie).

Je me rends donc sur http://www.winehq.org/ et sur la page dédiée à mon jeu favori (http://appdb.winehq.org/objectManager.php?sClass=version&iId=3126) j’apprends la nécessité d’avoir un patch non validé par la team Wine.

Comment patcher Wine proprement sous Fedora

Etape 1 : Récolte des fichiers

(Si vous ne disposez pas de yumdownloader)
yum install yum-util

(puis pour récupérer le src.rpm de wine)
yumdownloader –source wine

Concernant le patch, je vous conseille de vous armer de patience et de savoir parler anglais. Une fois le bon patch récupéré (pour la bonne version) exposez le fièrement :

a/dlls/kernel32/sync.c
+++ b/dlls/kernel32/sync.c
@@ -1826,12 +1826,12 @@ HANDLE WINAPI CreateIoCompletionPort(HANDLE hFileHandle, HANDLE hExistingComplet
TRACE(« (%p, %p, %08lx, %08x)\n »,
hFileHandle, hExistingCompletionPort, CompletionKey, dwNumberOfConcurrentThreads);

– if (hExistingCompletionPort && hFileHandle == INVALID_HANDLE_VALUE)
+/* if (hExistingCompletionPort && hFileHandle == INVALID_HANDLE_VALUE)*/
{
SetLastError( ERROR_INVALID_PARAMETER);
return NULL;
}

+#if 0
if (hExistingCompletionPort)
ret = hExistingCompletionPort;
else
@@ -1858,6 +1858,7 @@ fail:
CloseHandle( ret );
SetLastError( RtlNtStatusToDosError(status) );
return 0;
+#endif
}

/******************************************************************************
À SAVOIR : les zones en gras seront à supprimer, elles ne correspondent pas à la structure réelle utilisée pendant la construction du rpm.

Étape 2 : Préparation des fichiers

(installation des sources dans les dossiers /usr/src/redhat/)
rpm -i wine-1.1.5-1.fc9.src.rpm

copiez aussi votre patch dans le dossier /usr/src/redhat/SOURCES/

Étape 3 : Modification du fichier SPEC

Dans le fichier /usr/src/redhat/SPECS/wine.spec il faut :

  • Augmenter le numéro de release d’un(+1) pour éviter un conflit avec la version existant.
  • Indiquer la présence d’un nouveau patch
  • Indiquer l’exécution du patch
  • Remplir le changelog si vous souhaitiez partager ce rpm

Name: wine
Version: 1.1.5
Release: 2%{?dist}

Source300: wine-mime-msi.desktop

# enhancements
Source400: wineshelllink-fedora
Patch400: wine-wineshelllink.patch

# explain how to use wine with pulseaudio
Source402: README-FEDORA-PULSEAUDIO

Patch1: wine-rpath.patch

# fix #448338
Patch2: wine-desktop-mime.patch

# fix: I/O completion
Patch3: wine-completion-disable.patch

Buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

etup -q -n %{name}-%{version}-fe
%patch1
%patch2
%patch3
%patch400

%build

%changelog
* Sat Nov 02 2008 Bodman
– 1.1.5-2
– I/O fix

Etape 4 – Compilation du RPM

Wine n’est compilable qu’en version i386. Mais ne vous inquiétez pas que vous soyez sur i386 ou x64, cela ne change rien.

Il y a un certain nombre de dépendances pour wine ….

yum install alsa-lib-devel.i386 alsa-lib-devel audiofile-devel.i386 audiofile-devel cups-devel.i386 cups-devel dbus-devel.i386 dbus-devel esound-devel.i386 esound-devel fontconfig-devel.i386 fontconfig-devel freetype-devel.i386 freetype-devel giflib-devel.i386 giflib-devel hal-devel.i386 hal-devel lcms-devel.i386 lcms-devel libICE-devel.i386 libICE-devel libjpeg-devel.i386 libjpeg-devel libpng-devel.i386 libpng-devel libSM-devel.i386 libSM-devel libusb-devel.i386 libusb-devel libX11-devel.i386 libX11-devel libXau-devel.i386 libXau-devel libXcomposite-devel.i386 libXcomposite-devel libXcursor-devel.i386 libXcursor-devel libXext-devel.i386 libXext-devel libXi-devel.i386 libXi-devel libXinerama-devel.i386 libXinerama-devel libxml2-devel.i386 libxml2-devel libXrandr-devel.i386 libXrandr-devel libXrender-devel.i386 libXrender-devel libxslt-devel.i386 libxslt-devel libXt-devel.i386 libXt-devel libXv-devel.i386 libXv-devel libXxf86vm-devel.i386 libXxf86vm-devel mesa-libGL-devel.i386 mesa-libGL-devel mesa-libGLU-devel.i386 mesa-libGLU-devel ncurses-devel.i386 ncurses-devel openldap-devel.i386 openldap-devel openssl-devel.i386 openssl-devel zlib-devel.i386 pkgconfig sane-backends-devel.i386 sane-backends-devel xorg-x11-proto-devel.i386 xorg-x11-proto-devel glibc-devel.i386 prelink fontforge flex bison

Pour ma part les paquets alsa-lib-devel giflib-devel et libusb-devel en version i386 entre en conflit avec mes paquets x64 :

yum remove alsa-lib-devel* giflib-devel* libusb-devel*
yum install alsa-lib-devel.i386 giflib-devel.i386 libusb-devel.i386 esound-devel.i386 gphoto2-devel.i386 sane-backends-devel.i386

(Compilation des RPMs)
cd /usr/src/redhat/SPECS/
rpmbuild -ba wine.spec –target i386

(Installation de Wine patché)
cd /usr/src/redhat/RPM/
rpm -Uvh wine-*1.1.5-2.fc9.i386.rpm

bien sûr en cas de mise à jour de wine plusieurs solutions s’offrent à vous :

  • Patcher la nouvelle version.
  • Bloquer les mises à jour automatiques de wine
  • proposer votre patch à la personne responsable du paquet wine de votre distribution favorite.

Sources :

Patch  : http://bugs.winehq.org/attachment.cgi?id=8368

compilation wine sur x64 : http://wiki.winehq.org/WineOn64bit

EGroupWare sous Fedora 9

Depuis toujours, je suis à la recherche d’un logiciel combinant Mail/Agenda/IM. Ce logiciel n’existe pas, je m’y suis résolu. J’ai essayé pas mal de logiciels pour compenser mon manque. Les plus connus y sont passés.

Mon dernier choix était Evolution / Pidgin. Parfaitement intégrés à gnome, avec un possible agenda commun c’était le duo idéal. Mais voila evolution n’est pas stable lorsqu’il s’agit d’un usage intensif …

J’ai donc décidé d’innover et de passer à une interface WEB, un bureau virtuel. La transition risque d’être longue et difficile, mais j’espère un resultat optimal. Dans mes rêves les plus fous, ce serait encore mieux qu’un client lourd, car disponible depuis n’importe ou.

Plan de migration

  1. Cette transition va commencer par l’agenda
    • Exportation des anciens rendez-vous
    • Exportation des anciennes taches
    • Usage progressif du nouvel agenda
  2. Ensuite va suivre le carnet d’adresses.
  3. Pour finir, d’ici plusieurs mois, je vais faire une tentative de serveur imap centralisant tout mes mails et disponible par cette interface Web.

Installation

Pourquoi le choix de EgroupWare ? Parce qu’il me semble assez complet et qu’il dispose d’un depot Fedora!

Ce depot est disponible ici :

http://download.opensuse.org/repositories/server:/eGroupWare/Fedora_8/

Il suffit alors de récupérer le fichier repos et de le copier dans le dossier /etc/yum.repos.d :

http://download.opensuse.org/repositories/server:/eGroupWare/Fedora_8/server:eGroupWare.repo

Ensuite un petit yum install s’impose :

[root@localhost yum.repos.d]# yum install eGroupWare

Configuration du processus d'installation

Traitement des options d'installation des paquetages

Résolution des dépendances

--> Lancement de la transaction de test

---> Paquetage eGroupWare.noarch 0:1.4.004-15.1 marqué pour être mis à jour

--> Traitement de la dépendance : eGroupWare-egw-pear = 1.4.004 pour le paquetage : eGroupWare

--> Traitement de la dépendance : php-gd pour le paquetage : eGroupWare

--> Traitement de la dépendance : php-mbstring pour le paquetage : eGroupWare

--> Traitement de la dépendance : php-imap pour le paquetage : eGroupWare

--> Lancement de la transaction de test

---> Paquetage eGroupWare-egw-pear.noarch 0:1.4.004-15.1 marqué pour être mis à jour

---> Paquetage php-gd.x86_64 0:5.2.6-2.fc9 marqué pour être mis à jour

---> Paquetage php-mbstring.x86_64 0:5.2.6-2.fc9 marqué pour être mis à jour

---> Paquetage php-imap.x86_64 0:5.2.6-2.fc9 marqué pour être mis à jour

--> Traitement de la dépendance : libc-client.so.2007()(64bit) pour le paquetage : php-imap

--> Lancement de la transaction de test

---> Paquetage libc-client.x86_64 0:2007b-1.fc9 marqué pour être mis à jour

--> Résolution des dépendances terminée
Dépendances résolues
================================================================================
Paquetage              Architecture Version         Dépôt                   Taille
================================================================================
Installation:
eGroupWare             noarch    1.4.004-15.1    server_eGroupWare        11 M
Installation pour dépendance:
eGroupWare-egw-pear    noarch    1.4.004-15.1    server_eGroupWare        85 k
libc-client            x86_64    2007b-1.fc9     updates-newkey          669 k
php-gd                 x86_64    5.2.6-2.fc9     updates-newkey          113 k
php-imap               x86_64    5.2.6-2.fc9     updates-newkey           49 k
php-mbstring           x86_64    5.2.6-2.fc9     updates-newkey          1.1 M
Transaction Summary
================================================================================
Install      6 Package(s)
Update       0 Package(s)
Remove       0 Package(s)
Taille totale des téléchargement : 13 M
Est-ce correct [o/N] : o
Téléchargement des paquetages :
(1/6): php-imap-5.2.6-2.fc9.x86_64.rpm                     |  49 kB     00:00
(2/6): eGroupWare-egw-pear-1.4.004-15.1.noarch.rpm         |  85 kB     00:00
(3/6): php-gd-5.2.6-2.fc9.x86_64.rpm                       | 113 kB     00:00
(4/6): libc-client-2007b-1.fc9.x86_64.rpm                  | 669 kB     00:01
(5/6): php-mbstring-5.2.6-2.fc9.x86_64.rpm                 | 1.1 MB     00:02
(6/6): eGroupWare-1.4.004-15.1.noarch.rpm                  |  11 MB     00:30
----------------------------------------------------------------------------------
Total                                             357 kB/s |  13 MB     00:38
attention: rpmts_HdrFromFdno: Entête V3 DSA signature: NOKEY, key ID b93e789f
Import de la clé GPG 0xB93E789F « server:eGroupWare OBS Project <server:eGroupWare@build.opensuse.org> » depuis http://download.opensuse.org/repositories/server:/eGroupWare/Fedora_8/repodata/repomd.xml.key
Est-ce correct [o/N] : o
Lancement de rpm_check_debug
Lancement de la transaction de test
Transaction de test terminée
Transaction de test réussie
Lancement de la transaction
Installation   : php-mbstring                                      [1/6]
Installation   : php-gd                                            [2/6]
Installation   : libc-client                                       [3/6]
Installation   : php-imap                                          [4/6]
Installation   : eGroupWare                                        [5/6]
Pour en savoir davantage, faites: « chcon --help ».
error: %post(eGroupWare-1.4.004-15.1.noarch) scriptlet failed, exit status 1
Installation   : eGroupWare-egw-pear                               [6/6]
Installé: eGroupWare.noarch 0:1.4.004-15.1
Dépendance installée: eGroupWare-egw-pear.noarch 0:1.4.004-15.1 libc-client.x86_64 0:2007b-1.fc9 php-gd.x86_64 0:5.2.6-2.fc9 php-imap.x86_64 0:5.2.6-2.fc9 php-mbstring.x86_64 0:5.2.6-2.fc9
Terminé !

La suite plus tard …

Ouverture de session automatique sous Fedora

Habitué à faire cette manœuvre avec l’interface graphique,  j’ai quelque peu cherché pour le configurer en ligne de commande.

Dans le fichier /etc/gdm/custom.conf, il faut ajouter ces quelques lignes :

[daemon]
TimedLoginEnable=true
TimedLogin=Pseudo_a_charger
TimedLoginDelay=5

Après 5 secondes, la session s'ouvrira automatiquement.

Plus d'informations concernant ce fichier sur le site officiel : http://live.gnome.org/GDM/2.22/Configuration

Appareil photo Kodak et Linux

Le problème avec les Kodak c’est qu’ils ne se comportent pas comme une clef USB. Pour récupérer les photos sous Fedora il faut donc utiliser une GUI d’importation.
Seulement voila, lorsqu’il y a des vidéos dans l’appareil, allez savoir pourquoi, l’importation ne fonctionne plus (quelque soit le fichier).
Pour palier à ce problème j’ai trouvé la ruse ultime! Il suffit d’utiliser gphoto2 en ligne de commande.

Premièrement détecter l’appareil photo : gphoto2 –auto-detect
Il est ensuite possible de vérifier les fonctionnalités disponibles : gphoto2 -a
Pour importer les photos dans le dossier courant il ne reste plus qu’à faire : gphoto2 -P

A savoir , il est possible d’importer les prévisualisations (thumbs), seulement il semblerait que, dans mon cas, ce soit cette étape qui dérange la GUI habituelle :

gphoto2 –get-all-thumbnails

Voici mon erreur :

Téléchargement de ‘100_0121.JPG’ du dossier ‘/store_00010001/DCIM/100KM883’…
Enregistrement du fichier sous thumb_100_0121.jpg
Téléchargement de ‘100_0122.JPG’ du dossier ‘/store_00010001/DCIM/100KM883’…
Enregistrement du fichier sous thumb_100_0122.jpg
Téléchargement de ‘100_0123.MOV‘ du dossier ‘/store_00010001/DCIM/100KM883’…

*** Erreur ***
PTP erreur d’entrée sortie
*** Erreur (-1 : « Erreur indéfinie ») ***

Pour obtenir les messages de débogage, veuillez utiliser l’option –debug.
Ces messages peuvent aider à trouver une solution à votre problème. Si vous
avez l’intention d’envoyer un message d’erreur ou de débogage à la liste de
distribution des développeurs gPhoto ,
ce message devant être rédigé en anglais, veuillez lancer gphoto2
comme suit :

env LANG=C gphoto2 –debug –debug-logfile=my-logfile.txt –get-all-thumbnails

Please make sure there is sufficient quoting around the arguments.

Source : http://www.linuxdevcenter.com/pub/a/linux/2005/01/06/digicam.html