Reprise du message précédent :
Je suis en utf-8 si ça peut aider.

bonsoir,
j'essaye d'installer un paquet provenant du dépot http://www.debian-multimedia.org je suis en stable 64
seulement lors du update j'ai ce message d'erreur :  

 
merci de votre aide

google sur 'E: Dynamic MMap ran out of room'
 
(faut augmenter la taille maxi de la ram utilisable par apt)

merci c'était bien ça.

En fait, à ce niveau, c'est même un peu plus simple que ça.    
 
Les paquets dans testing ne sont pas backportés ; ils transitent tels quels depuis unstable dès qu'ils satisfont les critères d'inclusion de testing (un ensemble de scripts -connus sous le doux nom de "Britney"- se chargent couramment de cette opération, sauf dans le cas de mises à jour délicates qui requièrent une intervention manuelle de la part des Release Managers).

Tiens au fait je me rends compte que j'avais posté mon script debcheck ici à une époque, et depuis packages.debian.org (et donc mon script) a été mis à jour. Au cas (improbable) où ca intéresserait quelqu'un, je poste la nouvelle version

Dites, ça fais quelque temps que je suis sur debian    
Et ya un truc que je trouve bizar... Je suis en testing, et ya pas de paquet pour nvidia-glx, alors qu'il est présent en unstable et en stable, pourquoi?  

 
 
http://bjorn.haxx.se/debian/testing.pl

Merci  
Mais je me demande si ça ne vaudrais pas le coup de passer en unstable. C'est beaucoup plus bugger que testing?

 
On peut tout à fait mélanger les 2.
Tu mets dans ton sources.list les sources testing et les sources unstable
Tu mets dans un apt_preferences que tu choisis de privilégier testing, même s'il y a plus récent dans unstable (parce que sinon le comportement par défaut c'est toujours d'installer le plus récent disponible)
 
Et après :
si un paquet n'est que dans unstable : aptitude install lepaquet  
si un paquet est dans testing et dans unstable : aptitude install lepaquet (installe la version testing) ou aptitude install lepaquet/unstable (installe la version unstable)
 
Sinon unstable est pas si unstable que ça, mais certain jours ca peut être un peu cassé

C'est ce que je me disais, j'étais tomber la dessus en cherchant http://www.bxlug.be/articles/194
Merci beaucoup, je vais en profiter pour mettre nautilus 2.20 aussi.
Apres, aux mise à jour, les paquets installer à partir de unstable, sont mis a jour a chaque mise a jour de unstable, ou il faut toujours preciser?

Tant qu'un paquet garde une version plus récente que celle de testing, il est mis à jour à partir d'unstable. Si tu ne mets pas à jour pendant trop longtemps (ou si la version testing devient égale à la version sid) ton paquet est considéré comme venant de testing et est mis à jour à partir de cette distrib.

Ok, donc, faudrais plutôt éviter d'en abuser.  
En tout cas merci pour les renseignement  

Clairement. Si tu tire nautilus de sid, tu va rappatrier la moitié de gnome sid, à mon avis c'est une sale idée.

C'est ce que je veus éviter...    
Je pense que je vais prendre vlc, nvidia-glx (et donc le kernel aussi), et ptet éventuellement open office en fonction du nombre de dépendance.

Tu peux aussi prendre le parti d'attendre quelques jours/semaines, le temps que les paquets qui t'intéressent soient versés dans testing...

J'ai l'impression que nvidia-glx et vlc sont complètement absent de testing a part quand la sortie de la finale est proche  

Bonsoir,  
 
 
Depuis quelques temps, je constate une forte baisse de réactivité de ma Debian Sid lors de la copie de fichiers.  
 
Pour vous donner un ordre d'idée, un cas concret : je lance copie de, disons, 1.5 Go de données (ça peut aussi bien être 2 fichiers de 750 Mo, que 8 fichiers de 200 Mo environ) ; au bout de quelques instants à peine, et pendant toute la durée de la copie ensuite, mes applications KDE subissent de grosses latences dès que je tente une opération quelconque (par ex. : un simple changement d'onglet dans Konqueror prend jusqu'à 6 longues secondes...).
 
 
J'ai d'abord pensé que le problème pouvait venir de FAM qui, depuis les versions récentes, a tendance à partir quelquefois en sucette chez moi sous Konqueror, mais même en le désactivant ça ne change rien... J'ai ensuite essayé une copie sans passer par Konqueror, en faisant un bête cp en ligne de commande, mais le problème persiste toujours. Pour finir j'ai  tenté de changer la priorité d'exécution de cp avec un renice à 19, mais pareil, aucune amélioration...
 
 
Ma configuration est un tant soi peu optimisée, rien ne justifie ou n'explique pourquoi ce phénomène se produit :
 
Noyau 2.6.22 preemptif (customisé par mes soins à partir des sources Debian : linux-source-2.6.22-5), principales options pouvant avoir une incidence sur la réactivité du système :

 
La sortie de mon hdparm (également configuré de manière optimale par rapport à mon disque dur) :

 
 
Enfin, pour finir, mes partitions sont formatées en ReiserFS (3.6).
 
 
Quelqu'un a-t-il le même problème, ou a-t-il déjà rencontré le même problème ? Des idées pour le résoudre ? Dois-je faire un rapport de bug ?    

j'avais déjà eu des problèmes de débit qui chutaient dramatiquement, du genre copie de gros fichiers ReiserFS -> Fat32 qui finissaient avec un débit proche des 5 Mo/s, mais jamais d'impact sur la latence.
Tu as essayé avec un noyau "stock" pour tester si ce sont tes customisations qui sont à incriminer ? Tu n'as pas un chapelet d'erreurs d'écriture dans les logs ?

J'ai aussi rencontré ce genre de problèmes, mais c'était sur un montage NFS alors je pensais que ça venait juste du réseau.
 
Je vais vérifier si j'observe le même comportement avec des écritures standard sur le disque (ext3 pour moi) et je te tiens au courant.
 

Hello,
 
Est-ce que quelqu'un a installé vlc sur une Lenny, en utilisant soit les dépôts de Etch ou de Sid, et a réussi à faire que ça marche avec les annonces SAP.
J'ai essayé avec le vlc de Etch hier et il plante quand je lui demande de lister les annonces SAP (le reste fonctionne bien...).
Je sais pas trop où chercher ce qui ne va pas...    
Merci.
 
a+

 
testing n'est pas une véritable version de Debian. C'est plutôt un lieu de transit pour des paquets sid ayant été testés depuis pas mal de temps. C'est pourquoi, surtout après la publication de stable, il peut y avoir des paquets absents de testing alors que ce n'est pas le cas en sid. Le seul souci avec sid c'est de tomber sur des bugs sévères. Il faut aussi faire des mises à jour majeures de temps en temps pour la remettre au carré.

Bonjour,  
merci pour vos commentaires.    
 
 

J'ai déjà observé ce type de problème une fois ; le débit commençait à chuter progressivement une fois le cache d'écriture du disque saturé. Ce n'est pas le cas ici (je conserve un débit moyen de 22 Mo/s -mon disque n'étant pas très véloce) et à la limite ce serait moins dérangeant que mon problème de latence, dans la mesure où le système resterait utilisable pendant une copie.
 

Non je n'ai pas encore testé avec un noyau made in Debian ; je tenterai le coup pour voir.
Au niveau des logs rien d'anormal, à part acpid qui s'obstine à vouloir me retourner des évènements batterie malgré la présence du fichier /etc/acpi/events.ignore/events.ignore (peut-être un autre bug   ).
 
 
Sinon j'ai encore fait un rapide test ce matin sur mon ultraportable avec Etch, en copiant 3 images ISO de 650 Mo chacune : et bien (et c'est tant mieux) pas de problème particulier ; on observe une très légère latence à certains moments durant la copie, mais le système reste parfaitement utilisable ; rien de gênant, à part peut-être le temps de démarrage plus long pour les applis qui n'ont pas été lancées précédemment (ce qui est normal).
 
À noter que j'utilise dessus également un noyau avec des customisations similaires ; outre le fait que les versions de noyau ne sont pas identiques (c'est un 2.6.18 sous Etch), la seule différence concerne le mode préemptif, réglé en "CONFIG_PREEMPT_VOLUNTARY=y" (volontary desktop) au lieu de "CONFIG_PREEMPT=y" (low latency desktop) + "CONFIG_PREEMPT_BKL=y".
 
C'est étrange, car logiquement on devrait obtenir de meilleurs résultats dans le second cas (sous Sid donc) or c'est justement l'inverse. Peut être que la latence réduite ne s'applique que dans le cas tâche et ne profite pas dans le cas de tâches multiples s'exécutant en parallèle... Bien sûr ce ne sont que des hypothèses, le problème peut très bien venir d'ailleurs, vu les différences entre Etch et Sid ; à noter aussi que j'utilise ext3 (partitions système) + XFS (partitions de données) sous Etch et que, dans les deux cas, le taux d'occupation du CPU n'est pas à son maximum pendant la copie.
 
 
 

Peut-être que le problème ne se pose que dans le cas de la copie locale de fichiers chez moi ; je n'ai par exemple pas essayé de faire une copie de fichiers sur un volume distant uniquement, ça vaudrait le coup que je fasse le test de ce côté aussi pour voir si les accès sur mon disque sont à incriminer.
 

Ton retour sera toujours le bienvenu.    

Dans l'absolu oui, on pourrait voir les choses de cette façon, mais cependant il n'est pas exact de dire qu'il ne s'agit pas d'une version de Debian à part entière dans la mesure où celle-ci est tout de même disponible sous la forme de médias classiques (CD/DVD) et installable indépendamment de stable ou unstable.
 
   ---> cf. la page des versions sur le site Debian
 

Mmm... Je peux te dire d'expérience que la seule véritable version c'est la stable, ensuite sid puis testing. De plus les mises à jour de sécu ne sont vraiment suivis que sur stable. Je vois testing comme un pool de paquets à tester avant de les intégrer à la version officielle. Souvent après une mise à jour, il y a des trous qui sont comblés et d'autres créés.
 
Pour testing/sid il n'y a pas de cd/dvd finalisé, ce sont des mises à jour hebdomadaire de l'état des paquet, rien de plus. On peut les suivre au jour le jour évidemment. C'est moins vrai pour testing à la veille de la publication de stable, puisque sur la fin tout est gelé.
 
-> http://www.debian.org/CD/http-ftp/

Bon, pour ceux que ça intéresse, SAP ça marche avec vlc de Sid, pas avec vlc de Etch, j'ai testé pour vous    
 

 
Concernant les versions de Debian, je vois pas pourquoi testing serait moins une distribution que unstable? J'aurais plutôt dit l'inverse, d'ailleurs Sid ne pourra jamais être gelée en version stable, alors que testing finit par devenir stable... En plus, une version de Debian sans mises à jour de sécurité sur security.debian.org, ça colle pas bien à l'esprit "indestructible à moins d'utiliser des missiles nucléaires" de Debian...    M'enfin bon, c'est que mon humble avis perso    
 
a+

Sid est plus une version au sens littéral du mot parce que ses paquets sont cohérents (en tout cas plus que ceux de testing...). Il y a des bugs sur sid mais pas de dépendances cassées. Au début du cycle, les développeurs s'accordent à dire que Testing peut-être moins utilisable que Sid, c'est tout dire...
 
ex : du temps de etch en testing, il a fallu attendre des mois avant d'avoir kaffeine et d'autres applis kde utilisables parce qu'une librairie essentielle était tout simplement absente.

faire un git bisect sur ton kernel pour voir si ca vient de la ?

C'est ton point de vue ; dans mon précédent post, je me basais simplement sur les explications officielles fournies sur le site de Debian. Après tout est une question d'interprétation (certains diront du pinaillage).
 
Si on parle de version _publique_ alors on peut considérer que seul stable est une véritable version, testing et unstable restant purement des versions de développement. En fait, il est sans doute plus raisonnable d'utiliser le terme "branche" que le terme "version" lorsqu'on parle de stable, testing ou unstable, car on fait alors référence au cycle de développement de la distribution proprement dit.
 
 

Cette affirmation est tout simplement fausse : il arrive assez fréquemment qu'il y ait des dépendances cassées dans unstable ; c'est même un des critères empêchant l'intégration de certains paquets dans testing.
 
Rappelons-le, dans testing le but est d'éviter autant que possible la présence de bugs critiques tout en conservant un maximum de cohérence au niveau des dépendances entre paquets. C'est d'ailleurs pour cette raison d'une part que certains ensemble de paquets ne peuvent transiter que par "blocs", et d'autre part que des paquets peuvent se trouver indisponibles pour une durée très variables (cf. ton exemple avec Kaffeine).
 
À ce sujet, les explications fournies par Anthony Towns (qui a implémenté testing) sont assez claires :

En fait c'est une méthode pour trouver quel patch cause un probleme. Par dichotomie on essaye réduit un "ensemble" de patch.
Tu prends une arborescence "git" où le probleme est, tu prends une  autre où le probleme n'est pas. En lancant cette commande tu prends le "milieu" tu refais tes test, tu réduis l'intervalle et ainsi de suite.
A la fin il ne va rester qu'un seul patch qui va déterminer d'où vient le bug.

Méthode mieux expliquée : http://kerneltrap.org/node/11753

 
Jamais rencontré en 6 ans d'utilisation quotidienne... Des bugs, des mises au carré nécessaires (dist-upgrade) oui.  Bcp d'utilisateur de Debian te le confirmeront : testing est parfois plus sauvage que Sid (tu trouveras sûrement du grain à moudre à ce sujet ici : http://forum.debian-fr.org/). Il faut suivre une sid au jour le jour ou la geler et faire des dist-upgrade qd on y est forcé (besoin d'un nouveau package ou d'une nouvelle version par ex). Des mises à jour limitées cassent les dépendances communes (lib en générale) entre les nouveaux paquets et d'autres plus vieux qui réclament l'ancienne mouture. Les dépendances cassés ne sont pas tolérées par les outils de gestion des paquets (apt-get, aptitude etc), ils sont corrigés automatiquement lors d'une install ou bloquent toute installation de nouveaux paquets. Aucune sid dans cet état ne serait gérable... (ça était le cas certains mois avec etch testing). Ce sont les bugs critiques sur les paquets qui bloquent la migration vers testing ou une existence dans sid < 10 jours. Il y a un outil donnant les raisons pour lesquelles un paquet donné est bloqué en sid :
 
http://bjorn.haxx.se/debian/
 
Je vois mal pourquoi un paquet serait mis à disposition dans sid si ses dépendances sont absentes ou dans la mauvaise version : il serait impossible à utiliser. Il y a la branche "experimental" pour faire des test, sid est une version opérationnelle même si elle est en permanence très jeune.  
 
Le pb qui s'est produit avec etch testing, c'est justement qu'une lib était bloquée en sid. Il est évident que malgré les règles édictées pour faire migrer les paquets, il y a des cas de force majeure (en l'occurrence, je ne m'étais pas documenté sur la raison du blocage). Bref il y a la théorie et ce qui est humainement possible
 
A propose des règles, il y a aussi ces exceptions officielles :
 

> enfoiro & o'gure :

Ok, je comprends mieux ; intéressant mais au des manips' à faire je ne suis pas super motivé
J'ai l'impression que ça s'adresse plus au développeur noyau ou alors au mec qui passe son temps à le debugguer ; l'un de vous l'a-t-il testé/utilisé ?

> bluenotee :

Oui, je suis d'accord    ; je n'ai jamais dit qu'il n'y avait pas de problèmes avec testing, certains pouvant être sévères.

Cependant le nombre de bugs ouverts y est tout de même moindre que dans unstable, tout simplement. Par exemple, il y a actuellement près de 1700 bugs RC dans unstable contre un peu plus de 600 dans testing et un peu plus de 500 dans stable (cf. le graphe du statut des bugs RC) ; c'est un fait, on pourrait même aller jusqu'à dire qu'en ce moment testing est certainement dans un état plus proche de stable que de unstable.

Pour ma part je n'ai jamais eu de problème vraiment bloquant que ce soit avec testing ou unstable (et stable également bien sûr) ; maintenant j'ai toujours fait attention lors des mises à jour à la fois en me tenant au courant des changements important dans la distribution et en m'aidant de apt-listbugs qui permet d'éviter quelques mauvaises surprises de temps à autre.  

Dites les gens de Debian Sid, vous arrivez à installer le paquet policykit et libpokit ?
Il est présent dans les dépôts, et pourtant je ne le trouve pas avec aptitude ...

edit : non j'ai rien dit
/sifflote

Je ne vois aucun des deux paquets ni en lenny ni en sid... Tu es sûr des noms ?
 

Ah oui, pour ça... Mais on est en début de cycle, 600 bugs connus pour la testing, c'est la partie émergée de l'iceberg. D'ailleurs, on ne parle que des bugs "critical, grave et serious", on peut s'arracher les cheveux pour moins que ça. D'ici un an, elle sera épurée Je me demande si ce sont les mêmes niveaux de bugs (sur le graphe) pour la stable ou si pour elle, TOUS sont indiqués. En tout cas, elle a tourné 2 ans de plus, le poisson se fait rare tandis que pour testing, la pêche est ouverte (c'est un peu la "masse manquante", invisible sur le graphe)
Sans parler des surprises : le coup de stress de janvier 2006 qui ne correspond pas à une sortie de version officielle. Je ne sais plus à quoi ça correspondait (quels packages sortant de sid ??) De quoi calmer les impatients
 
De mon côté, j'ai tjs eu bcp de processus fous avec sid, et 2 bugs. Avec testing, un bug important, corrigé dans la semaine du tps de Sarge. J'ai repris testing récemment pour faire tourner du matériel récent et j'ai eu un bug important, corrigé en 3 semaines mais en testing/sid, je ne mets à jour (tous les paquets) que qd je suis coincé. Avec stable, je n'ai jamais rien découvert.

Quand je "suivais" la lkml j'avais testé "juste comme ca", mais bon ca prend un peu de temps. C'est plus pour les dev/testeur.

Oui, c'est dans experimental en fait

Ca va être sportif, alors !

pas testé.
set de manips plus simples pour détecter un bug kernel :
- compiler un kernel vanilla (venant de kernel.org) de même version avec les mêmes options de config : le fichier debian sera utilisé par défaut, ensuite utiliser make-kpkg => bug ?
- utiliser des paquets debian plus anciens et vérifier la présence du bug.
- utiliser un kernel vanilla plus ancien et vérifier l'apparition du bug.
les patchs debian peuvent être à l'origine du bug, d'où le kernel vanilla.
tu aidera la communauté

Depuis quelques temps ma Debian SID consomme énormément de RAM.
Avant je pensais que ca venait de mes 70+ onglets sous Konqueror ou Firefox mais là, avec Konqueror 4 onglets et Firefox 10 onglets, + KDE, + Amarok je suis rapidement à bout de ma mémoire. Xorg monte très haut, environ 700Mo mais dès que je vire Firefox il redescend tout de même vers les 300Mo.
 
Ce qui fait que ca swap etc c'est l'enfer. Pourtant 512 de RAM ce n'est pas si mal non? on n'est pas sous longue corne pourtant