Télécharger le .tar.gz ici : http://mir7.ovh.net/ovh-applications/hubic/hubiC-Linux/1.1.13/

L’extraire (tar zvxf). Aller dans le dossier en console et taper :

sudo make
(cela suppose que vous avez make installé…)

Installer mono, mono-data et mono-sqlite :

sudo yum install mono-core mono-data-sqlite mono-data

Exporter la variable de session DBUS comme indiqué sur leurs forums :


$ dbus-launch --sh-syntax
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-XXXX,guid=XXXXXXX
DBUS_SESSION_BUS_PID=1234
$ export DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-XXXX,guid=XXXXXXX
(les lignes précédées de « $ » sont les lignes que vous devez exécuter, en mode utilisateur (sans sudo), les lignes sans « $ » devant sont juste un exemple de retour/sortie de la commande exécutée)

Lancer le service d’abord :

/usr/local/lib/hubic/hubic-service

Et effectuer le login après :

hubic login [email protected] /dossier/de/synchro/hubic

Vous devriez voir, dans la console où vous avez lancé le service hubic, des lignes du genre :

[INFO | 1/2/2014 11:15:43 AM | Ovh.Hubic.Sync.Linux.CLI.Server.MainLoop] Application starts (Version: 1.1.13.22-64; Platform: Unix 3.12.5.200)
[ERROR | 1/2/2014 11:15:45 AM | Ovh.Hubic.Sync.Model.OnLogin] Can't connect: (Calling: https://ws.ovh.com/hubic/r5/rest.dispatcher/getHubics, Status: NOT_FOUND) Compte non trouvé
[WARN | 1/2/2014 11:16:15 AM | Ovh.Hubic.Sync.AI.Indexer.Index] Synchronization default has never been synced. Synchronize it from scratch.
[INFO | 1/2/2014 11:16:15 AM | Ovh.Hubic.Sync.AI.ChangeProcessor.DoLocalMkdir] Local mkdir: /home/vous/hubic/Videos (for {default}/Videos)
[INFO | 1/2/2014 11:16:15 AM | Ovh.Hubic.Sync.AI.ChangeProcessor.DoLocalMkdir] Local mkdir: /home/vous/hubic/Images (for {default}/Images)
[INFO | 1/2/2014 11:16:15 AM | Ovh.Hubic.Sync.AI.ChangeProcessor.DoLocalMkdir] Local mkdir: /home/vous/hubic/Documents (for {default}/Documents)
[INFO | 1/2/2014 11:16:15 AM | Ovh.Hubic.Sync.AI.ChangeProcessor.DoSetSyncTag] Set synchronization tag on default.

Pour la partie concernant DBus, il est possible que cela marche sans la faire, à vous de tester. Le plus important est de bien lancer d’abord le service et le login ensuite.

(note : Merci également à MLO où j’ai trouvé des infos : http://www.mageialinux-online.org/forum/topic-16704+synchronization-hubic.php )

Just a quick tip, it seems that in some cases, when Fedora startup scripts do not manage to do a fsck check on the root volume, they will not start X server and just display a message saying something went wrong and you cannot either type the root password and figure it out yourself or press Control-D to continue.

So, this might not be the right solution for you but check out whether you got something like that in your logs :


- Unit systemd-remount-fs.service has begun starting up.
Jan 01 15:06:08 fedora-user.localdomain systemd[1]: Unit systemd-fsck-root.service entered failed state.
Jan 01 15:06:08 fedora-user.localdomain systemd[1]: Failed to start File System Check on Root Device.


In order to check that, when you’re asked whether to type Ctrl-D or your root password, at startup, type the root password and press Enter.

Then, type « journcalctl -xb » and look at the red lines to see if you have something like that. Note that the newest lines will be at the bottom, so you might have to scroll quite a bit. Also note that you might have red lines that are not very important and not what you’re looking for, don’t stop at the first red lines.

If you do have some error messages like the ones I pasted above, the only way I found was to boot into a LiveUSB, access my LVM Group using this very useful how-to: http://stevedowe.me/2012/01/how-to-recover-that-encrypted-ext4-formatted-logical-volume-you-allowed-fedora-to-create.html
and run the fsck.ext4 check so that it corrects the partition corruptions / errors that were present.

I then rebooted… and everything went smooth !

Version en Français en bas de la version Anglaise…

In order to get MTP to work on Fedora 19 with Nautilus (sorry if you’re using another file browser, I did not test other ones (does not work with Thunar, that I normally use, I just switch to Nautilus for MTP and then back to Thunar…) run the following command :

sudo yum install -y gvfs-mtp

Maybe online forums will tell you « install gvfs » but in fact this is not enough! You have to install gvfs-mtp in order to get it to work.

Note that it works with MTP, not PTP, at least for me…

===============================================

Afin de faire marcher le MTP sur Fedora 19 avec Nautilus (désolé si vous utilisez un autre gestionnaire de fichier, je n’ai testé qu’avec Nautilus (je sais que ça ne fonctionne pas avec Thunar notamment, que j’utilise notamment… sauf pour le MTP, du coup)), lancez la commande suivante dans un terminal :
sudo yum install -y gvfs-mtp

Vous trouverez plein de forums en ligne qui vous diront « installe gvfs » mais ça ne suffit pas ! Il faut installer gvfs-mtp afin que ça fonctionne vraiment.

Remarque : Ça ne fonctionne qu’avec MTP, pas PTP… en tout cas pour moi…

(version Française en bas de la version Anglaise)

Keyboard shortcuts have been a thing that’s being broken at one upgrade over two on XFCE for a while, but there’s usually a way to find the workaround on the Internets.

Except… This time. (Murphy’s law). I have not had any chance finding the answer to this new broken keyboard shortcuts (ALT + F2, among others) after upgrading to XFCE 4.10 (on Fedora Linux 19 x64, but that might probably apply for other distros as well :D).

So, not sure if it’s going to work for you, but after trying one by one to remove files of my XFCE config folder, I found that this one is the faulty: ~/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml

Removing it (outside of a XFCE session, in TTY or using another Desktop Manager for instance) and restarting XFCE has solved the issue for me.

Just for reference, here’s the content of the file in my case : http://pastebin.com/y2Mdiwyt (in case someone is interested in debugging XFCE 4.10 ).

IF THIS DOES NOT WORK FOR YOU, here’s a tip: make a backup of your .config/xfce4 directory (cp ~/.config/xfce4 ~/.config/xfce4_bak -vR) and try to remove one by one files located in ~/.config/xfce4/xfconf/xfce-perchannel-xml/ and restart XFCE4 between each attempt, it will most likely come from one of them. Once you’ve found the faulty one, restore the rest of your backup and remove the one you’ve found is faulty. That’s what I did to figure out displays.xml was causing the bug.

During your tests, it’s also best to do a mv ~/.cache/sessions ~/.cache/sessions_bak in order not to interfere with your attemps, and restore it at the end.

——————————-

Et en bon vieux Français pour les Anglophobes (et les autres) :

Les raccourcis claviers ont toujours été une partie de XFCE4 qui est plus ou moins cassée à chaque mise à jour… Cependant, il y a généralement la solution quelque-part sur les Internetz…

Sauf… cette fois ! (Loi de Murphy). Ou alors je n’ai juste pas eu de chance en cherchant… Mais impossible de trouver de bidouille pour rectifier le souci cette fois-ci. Le souci ? Après mise à jour de XFCE vers la version 4.10 plus aucun raccourci clavier géré par XFCE ne fonctionne (ALT + F2 notamment).

Du coup, pas sûr que cela fonctionne pour vous, mais voici comment j’ai résolu le problème dans mon cas précis et après divers tentatives : supprimer le fichier ~/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml

La suppression de ce fichier (en dehors d’une session XFCE, en TTY ou depuis un autre gestionnaire de bureau (KDE, Gnome…)) et redémarrage de XFCE4 sont venus à bout de mon souci

Si ça en intéresse certains, voici ce que contenait mon fichier : http://pastebin.com/y2Mdiwyt (des fois que quelqu’un ait envie de débugger XFCE :))

SI CELA NE FONCTIONNE PAS POUR VOUS, je vous conseille : sauvegarde de votre dossier .config/xfce4 (cp ~/.config/xfce4 ~/.config/xfce4_bak -vR), puis tentez de supprimer un par un (en redémarrage XFCE4 entre chaque (juste réouvrir la session XFCE4)) les fichiers situés dans le dossier : ~/.config/xfce4/xfconf/xfce-perchannel-xml/

Cela viendra probablement d’un de ces fichiers Une fois que vous avez trouvé celui qui fait planter. Remettez votre dossier xfce4 original et supprimez ce fichier et cela devrait marcher C’est ce qui m’a permis de trouver le fichier, dans mon cas.

De plus, pendant que vous cherchez le fichier coupable, je vous conseille d’aussi virer temporairement le cache de session : mv ~/.cache/sessions ~/.cache/sessions_bak et le restaurer une fois le bug trouvé.

English readers : see at the bottom of the French version !!

Bon, après avoir passé 1h45 à tenter de faire marcher une bonne fois pour toute Spotify via Wine sur ma Fedora 16 64 bits (alors que ça marchait parfaitement quand j’étais sur FC15 … ), je me sens l’envie de partager la solution, car aucune de celles trouvées sur le web ne marchait dans mon cas présent.

Symptômes :

• Soit vous n’avez pas du tout de son dans Spotify
• Soit vous entendez un espèce de grésillement correspondant de manière trèèèèès lointaine à la musique que vous devriez entendre

La solution est assez complexe, voici la procédure que j’ai suivie afin de finalement arriver à avoir du son. Il en existe peut-être d’autres, mais celle-ci a fonctionné pour moi !

1. Désinstaller tous les paquets relatifs à Wine
2. Supprimer le dossier ~/.wine
3. Installer Wine en version 32 bits : sudo yum install wine-core.i686 wine-wow.i686
4. Installer le driver alsa (et uniquement lui) en version 32 bits : sudo yum install wine-alsa.i686
5. Installer Spotify à l’aide de l’installateur pour Windows.
6. Modifier le raccourci de lancement de Spotify (note : celui ci-dessous est le raccourci du menu « Applications » de Fedora. Si vous voulez éditer celui qui se met sur le bureau, la procédure est la même) :
   vi ~/.local/share/applications/wine/Programs/Spotify.desktop
   Ensuite, modifiez la ligne « EXEC » en rajoutant « padsp  » au début. Cela donne ceci pour moi : 

   [Desktop Entry]Name=SpotifyExec=padsp env WINEPREFIX="/home/troll/.wine" wine C:\\\\windows\\\\command\\\\start.exe /Unix /home/troll/.wine/dosdevices/c:/users/troll/Start\\ Menu/Programs/Spotify.lnkType=ApplicationStartupNotify=truePath=/home/troll/.wine/dosdevices/c:/users/troll/Application Data/SpotifyIcon=B29C_spotify.0

7. Lancer winecfg et le configurer avec les périphériques virtuels PulseAudio : padsp winecfg
8. Aller dans l’onglet « Audio » puis choisissez dans les périphériques audios, ceux qui correspondent au même nom que ce que vous pouvez trouver dans les Paramètres Systèmes de Fedora 16. Pour moi, c’était celui qui n’était ni « default » ni « system default » mais qui avait le nom de ma carte son. Valider.
9. Installer le paquet alsa-oss en version 64 bits : sudo yum install alsa-oss
10. Lancer Spotify via le raccourci qu’on a édité à l’étape 6.
11. Enjoy !

(Note : Ca ne résoudra peut-être pas les problèmes de lecture de la musique « locale », car là c’est un problème de décodeur MP3, il y a des explications ici : Spotify and local storage music[EN].)

—————————- English Version —————————-

After 1h45 of attempts to make Spotify working once for all via Wine on my Fedora 16 64 bits (whereas it worked perfectly on FC15 … ), I feel I want to share the solution, since none of the one I found on the web was actually working in my case !

Symptoms :

• Either you don’t have any sound in dans Spotify
• Or you only hear a sort of noise/garbage corresponding, from far and with super-ears, to the music you are actually trying to listen.

The solution is pretty complex, here is the steps I finally went through to get my Spotify via Wine on FC16 x84_64 working (it may exist some others, but these steps worked for me) :

1. Uninstall all Wine packages
2. Remove the ~/.wine directory
3. Install 32 bits version of Wine : sudo yum install wine-core.i686 wine-wow.i686
4. Install alsa driver (and only this one) in 32 bits version : sudo yum install wine-alsa.i686
5. Install Spotify using the Windows installer using Wine.
6. Edit the launch shortcut of Spotify (note : the one below is the shortcut of the « Applications » Fedora menu. If you want to edit the one located on you Desktop, the procedure is the same) :
   vi ~/.local/share/applications/wine/Programs/Spotify.desktop
   Then, change the « EXEC » line by adding « padsp  » at the beginning. This gave, for me :

   [Desktop Entry]Name=SpotifyExec=padsp env WINEPREFIX="/home/troll/.wine" wine C:\\\\windows\\\\command\\\\start.exe /Unix /home/troll/.wine/dosdevices/c:/users/troll/Start\\ Menu/Programs/Spotify.lnkType=ApplicationStartupNotify=truePath=/home/troll/.wine/dosdevices/c:/users/troll/Application Data/SpotifyIcon=B29C_spotify.0

7. Launch winecfg with the PulseAudio virtual devices to configure it with them : padsp winecfg
8. Go to « Audio » tab and choose, in the audio devices list, the ones corresponding to the name of those you can find in « System Settings » of Fedora. For me, it was neither « default » nor « system default » but the one which had the name of my sound card (HDA Intel blabla…). Validate.
9. Install the alsa-oss package in its 64 bits version : sudo yum install alsa-oss
10. Launch Spotify using the shortcut you edited and step 6.
11. Enjoy !

(Note : It surely won’t solve the problems related to playing « local storage music » because it is a MP3 decoding problem, you can find out more about the « local storage » music problem here : Spotify and local storage music.)

English readers : see at the bottom of the French version !!

Voulant installer Qt4 et QtCreator sur ma fedora 16 toute fraiche, je me suis heurté, lors de la première tentative de compilation, à une erreur pour le moins étonnante (lorsque j’ai fait « run qmake ») :

/usr/share/qt4/mkspecs/linux-g++/qmake.conf.

Après avoir fait une rapide recherche infructueuse sur le net, j’ai fait une petite recherche sur mon disque dur sur le terme « mkspecs » et je trouve qu’il se trouve en fait dans /usr/lib64/qt4/mkspecs.
Dans une tentative un peu naïve, je tente le lien symbolique, me disant que ça doit encore être une histoire de 64bits pas super bien géré :

sudo ln -s /usr/lib64/qt4/mkspecs /usr/share/qt4/mkspecs

Eh bien… ça marche !! Problème semble résolu, on dirait bien que ça compile même !
Avis aux amateurs qui auront le même souci, donc… Et si ça ne résoud pas le souci mais que vous avez une autre solution, ou que vous voulez apporter une quelconque info supplémentaire, ajoutez un commentaire !!

——————————- English Version ——————————-

Willing to install Qt4 & QtCreator on my fresh installed fedora 16, I have gone into some trouble…, at my first compilation attempt (« run qmake » attempt, actually), a surprising error pops-up :

/usr/share/qt4/mkspecs/linux-g++/qmake.conf.

After a quick and unsuccessful search on Google, I decided to make a quick search on my hard disk on « mkspecs » and I found that it seems to be in fact in /usr/lib64/qt4/mkspecs.
In a naive attempt, I try the symlink, thinking of a 64bits a bit bad-managed by the libraries paths :

sudo ln -s /usr/lib64/qt4/mkspecs /usr/share/qt4/mkspecs

Well… it works !! Issue solved, it seems, it even compiles !
If you have any additional information / solution, please feel free to add it in the comments below !

Ayant récemment installé Fedora 16 (FC16) tout marchait bien… jusqu’à une malencontreuse mise à jour ! (laquelle, je ne sais pas, vu leur nombre !).

Et là, plus de wifi…

Après avoir cherché des heures et des heures à bidouiller avec modprobe etc… j’ai regardé mon dmesg :

[ 239.100501] iwl3945 0000:06:00.0: iwlwifi-3945-2.ucode firmware file req failed: -2
[ 239.103276] iwl3945 0000:06:00.0: iwlwifi-3945-1.ucode firmware file req failed: -2
[ 239.103281] iwl3945 0000:06:00.0: Could not read microcode: -2
[ 345.378949] iwl3945 0000:06:00.0: iwlwifi-3945-2.ucode firmware file req failed: -2
[ 345.382280] iwl3945 0000:06:00.0: iwlwifi-3945-1.ucode firmware file req failed: -2
[ 345.382284] iwl3945 0000:06:00.0: Could not read microcode: -2

J’ai donc cherché si un driver correspondait, visiblement, je n’avais pas le bon ! (alors que lsmod me renvoit bien iwl3945 !)

yum search 3945
Repository google-chrome is listed more than once in the configuration
===================================================================== N/S Matched: 3945 =====================================================================
iwl3945-firmware.noarch : Firmware for Intel® PRO/Wireless 3945 A/B/G network adaptors

Il faut donc installer le paquet « iwl3945-firmware » :

(en root)
yum install iwl3945-firmware

Et voilà ! Maintenant, vous faites :

su
ifup wlan0

Et votre LED Wifi va enfin, enfin, enfin s’allumer .

Voici un micro-article (après la boulette de cette aprem… publication d’un brouillon par mégarde…) pour quand même mettre l’info à disposition sur Internet : Si vous cherchez sur Internet comment lire les MP3 sous Fedora vous allez tomber sur cette page : Lecture de fichiers multimédia sur Fedora.

Tout d’abord, il vous faudra, si ce n’est pas encore fait, installer les dépôts RPM Fusion (merci à Mezzo pour le rappel ). Ces dépôts contiennent à peu près… beaucoup de choses dont vous aurez besoin ! Notamment les pilotes graphiques pour Nvidia… etc. etc. … Bref, c’est un must-have, installons-les, pour cela, tapez les commandes suivantes dans une console (il va vous demander le mots de passe root, c’est normal vous allez installer un logiciel !) :

su -lc ‘yum install --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm‘
su -lc ‘yum install --nogpgcheck http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm‘

Si cette page est très intéressant, elle n’est cependant pas à jour. Dorénavant, Amarok sous Fedora utilise GStreamer, pour avoir les MP3 il vous faut donc installer les paquets suivants :

# yum install gstreamer-plugins-ugly gstreamer-ffmpeg

Un petit redémarrage d’Amarok peut s’imposer afin que ça fonctionne…