jlh a écrit 55 commentaires

La commande "udevadm test " attend un chemin vers un device en paramètre (udevadm test [options] [devpath]), pas un fichier .rules donc udev cherche un device qui s'appelle "usb-audio.rules" dans le dossier /sys d'où l'erreur (voir la page de man de la commande udevadm).

Il existe dog, une réimplémentation de dig en rust. C'est dans les dépôts de Archlinux.

Quelque chose comme :

create or replace view galette_athletics_speed_chal as
  select * from (
    select a.id_adh AS id_adh,
           re.id_race AS id_race,
           point_for_race(re.time,re.gender,ro.distance, NULL) AS points,
           point_bonus(re.category) as bonus,
           if((month(ra.race_date) < 9),(year(ra.race_date) - 1),year(ra.race_date)) AS saison,
           RANK() OVER (PARTITION BY a.id_adh ORDER BY re.id_race) AS rank
    from 
          galette_athletics_results re join galette_adherents a on a.id_adh = re.id_adh
                                       join galette_athletics_races ra  on ra.id_race = re.id_race
                                       join galette_athletics_routes ro on ro.id_route = ra.id_route 
    where ro.is_neutralized = 0 and ro.is_challenge = 1 
    group by saison, a.id_adh, points, bonus, id_race
  ) AS t
  WHERE t.rank <= 6
  ORDER BY t.saison desc, t.id_adh, t.points desc;

Plutôt que des espaces, je pense qu'il faut mettre des accolades autour des noms de variables collées à des chaînes de caractères :

${dossierSource}pupload

pour que le shell sache où commence et où finit le nom de la variable.

Je ne connais pas Redmine, mais on peut créer des scripts ruby et les lancer avec la commande : script/rails runner "script.rb"
(voir script/rails runner --help pour plus d'infos)

du compte root se trouve en bas de la page : http://eoleng.ac-dijon.fr/documentations/2.3/partielles/HTML/EOLE/co/03_deroulement.html

Je persiste avec les expressions régulières :

function bb_decode($txt) {

$title_reg = "/\[title\](.*?)\[\/title\]/";
$title_rep = "<span style='font-weight: bold; text-decoration: underline;'>\\1</span>";

$txt = preg_replace($title_reg, $title_rep, $txt);

$bold_reg = "/\[b\](.*?)\[\/b\]/";
$bold_rep = "<span style='font-weight: bold;'>\\1\</span>";

$txt = preg_replace($bold_reg, $bold_rep, $txt);

$underline_reg = "/\[u\](.*?)\[\/u\]/";
$underline_rep = "<span style='text-decoration: underline;'>\\1</span>";

$txt = preg_replace($underline_reg, $underline_rep, $txt);

$italic_reg = "/\[i\](.*?)\[\/i\]/";
$italic_rep = "<span style='font-style: italic;'>\\1</span>";

$txt = preg_replace($italic_reg, $italic_rep, $txt);

$email_reg = "/\[email\]([.\s]*?)\[\/email\]/";
$email_rep = "<a href='\\1'>\\1</a>";

$txt = preg_replace($email_reg, $email_rep, $txt);

$url_reg = "/\[url\](.*?)\[\/url\]/";
$url_rep = "<a href='\\1'>\\1</a>";

$txt = preg_replace($url_reg, $url_rep, $txt);

$color_rep = "<span style='color: \\1;'>\\2</span>";
$color_reg = "/\[color=([a-z]+?|\#[0-9a-fA-F]{6})\](.*?)\[\/color\]/";

$txt = preg_replace($color_reg, $color_rep, $txt);

# nettoyage des balises incomplètes
$balise_reg = "/\[\/?(title|b|u|i|email|url|color(=(.+?))?)\]/";

$txt = preg_replace($balise_reg, "", $txt);

return($txt);
}

Ça n'est pas complet, mais l'idée est là et ça semble fonctionner sur les quelques essais que j'ai fait.


if (preg_match('/\[title\](.*?)\[\/title\]/', $t, $result)) {
$t = "<span style='font-weight: bold; text-decoration:underline;'>". $result[1] . "<’/span>";
}

De cette façon, il faut à la fois une balise ouvrante et une balise fermante pour qu'il y ait un remplacement.

$result contient un résultat si la fonction preg_match réussie, avec $result[0] = la chaîne complète validant
l'expression régulière et $result[1] = contenu de la chaîne entre les balises [titre].

C'est l'option /apps/nautilus/preferences/show_desktop qui indique à
Nautilus s'il doit ou pas gérer le bureau ...

A vérifier avec gconf-editor.

J'imagine que c'est un système 32 bits donc cela peut provenir de la gestion du temps par le kernel ou un pilotes puisque
70 min ~= 2^32 microsecondes (ou un problème de compilateur).

Je n'ai pas de solution particulière si ce n'est d'essayer avec un kernel plus récent ou une autre version du compilateur.

Ta partition racine (/) est sur /dev/sda3 et le paramètre real_root pointe vers /dev/hda3, corrige ça et ça devrait mieux marcher ...

Plus précisement, il faudrait voir si le répertoire /dev n'utilise pas le système de fichier 'ramfs' et si c'est le cas, est-ce que le support a été inclu dans la config du kernel (CONFIG_RAMFS=y dans le fichier .config)

Il manque toujours les paramètres 'root=/dev/sda2' après 'kernel /boot/kernel-tuned' mais si cela fonctionne sans ....

Sinon pour le problème du mount, il faudrait peut-être voir dans le fichier /etc/fstab s'il n'y a pas quelque chose de louche....

Il faudrait donner le contenu du fichier grub.conf pour pouvoir te répondre correctement. Mais là, il semble manquer un paramètre
après la commande 'kernel' pour indiquer au noyau linux quelle est la partition correspondant à la racine du système de fichiers.

Donc normalement, dans le fichier grub.conf, tu devrais avoir quelque chose du genre :
root (hd0,0)
kernel root=/dev/sda2 ...

('root (hd0,0)' sert à grub pour trouver le fichier du kernel et
le paramètre 'root=/dev/sda2' sert au kernel à trouver la racine du système de fichier)

Ordoncque, après avoir lu le code , il semblerait qu'il y ait quelques fuites de mémoire qui traînent ...
blob, retblob, document et doctype se voient allouer de la mémoire qui n'est libérée nulle part à priori, ceci explique peut-être cela ?

Enfin une question qui n'a rien à voir avec le problème :
Pourquoi créer un blob avec le contenu de document juste pour le passer en paramètre à la fonction de compression ?
Pourquoi ne pas passer directement document à la fonction de compression et retourner un Magick::Blob ?

Il semble que ce qui est envoyé sur la sortie standard est
gardée dans un buffer.

2 solutions :
STDOUT.sync = true au début du programme
ce qui oblige à écrire au fur et à mesure vers la sortie standard

ou

STDOUT.flush à la fin qui vide le buffer.

non on ne peut pas ...
root (hd0,0) c'est pour Grub afin qu'il sache où trouver le kernel,
root=/dev/sda1 c'est pour le kernel pour qu'il sache où trouver la
partition racine du système.

Il faut modifier aussi le fichier /etc/fstab mais alors tu rend plus
difficile le boot sur le kernel 2.6.18 ...

Il semble qu'il est possible d'envoyer un signal 0 au processus surveillé tout les x secondes pour voir si il est toujours là avec la
fonction kill(pid, signal) (voir man 2 kill).
Plus de détail là :
http://www.linuxjunkies.org/html/Process-Monitor-HOWTO.html

pour le modèle Attansic L1 Gigabit Ethernet sur Sourceforge, voir :
http://sourceforge.net/project/showfiles.php?group_id=184921(...)
mais seules les sources sont disponibles donc il faudra compiler le module (les explications se trouvent dans le fichier README).

La bonne nouvelle est que le driver a été intégré au kernel début février et sera donc disponible dans la version 2.6.21 de celui-ci.

... il s'avère que d'autres personnes ont rencontrées le problème qui proviendrait d'une duplication de bibliothèques de fonctions avec une ancienne version dans /lib et une plus récente dans /usr/lib.

(voir : http://forums.gentoo.org/viewtopic.php?t=526911 )

Il faudrait plutôt voir si le module que X essaie de charger est bien le module glx de nvidia et pas le module glx mesa qui vient avec Xorg.

Il me semble que pour certaines distributions, il faut installer les paquets nvidia-kernel, nvidia-driver et nvidia-glx ... ou pas, c'est à vérifier.

Un développeur de The Gimp a implémenté ça il y a quelques semaines. Voilà un lien vers l'article de son blog où il en parle (en anglais) :
http://svenfoo.geekheim.de/index.php/2005-04-24/computationa(...)

Il faut dire à l'objet window de surveiller les mouvements de la souris ce qu'il ne fait pas par défaut et donc ajouter cet évenement à la liste des évenements que surveillent la Gtk::window avec un appel à
window.add_events(Gdk::Event::POINTER_MOTION_MASK)
avant la ligne window.signal_connect.

Voir là pour plus d'infos :
http://ruby-gnome2.sourceforge.jp/hiki.cgi?Ruby-GNOME2%20API(...)
et là
http://ruby-gnome2.sourceforge.jp/fr/hiki.cgi?tutoriels

Il faut enlever la ligne "exit 0" qui demande la sortie du fichier et donc les commandes suivantes ne sont pas exécutées.

Peut-être dans moon_find_envS(), la variable S2=&stack est allouée sur la pile,
et son adresse est retournée comme résultat en fin de fonction, mais cet espace mémoire doit être réutilisé après par d'autre fonctions.

Tu peux enlever la variable stack et remplacer le memcpy par un moonS_copy.

Mais ....
... dans moon_resolve, la variable parents est un pointeur vers une
zone mémoire allouée par un malloc et un peu plus loin, cette adresse est écrasée par : parents = moon_find_envS(parents);
donc tu ne peux plus libérer cette zone.