subject:"Backport"

pinning suite, quels outils système avec un noyau récent de jessie-backport

2016-07-22 Par sujet Daniel Caillibaud

Bonsoir,

J'ai installé un noyau récent de jessie-backports (4.6.0-0.bpo.1-amd64) parce 
que j'utilise
btrfs (et que les problèmes parfois rencontrés avec btrfs se raréfient avec les 
évolutions du
noyau).

J'ai donc pris aussi dans backports btrfs-progs (pour les mêmes raisons) et les 
paquets qui me
semblait assez liés au noyau (e2fslibs e2fsprogs irqbalance), mais quid de 
systemd
(voire d'autres) ?

J'aurais tendance à en prendre le moins possible dans backports, mais une fois 
que j'ai pris le
noyau est-ce plus prudent de prendre aussi le reste ?

PS1: on est encore vendredi et je sens déjà venir le troll avec backports+btrfs 
& prudent, mais
c'est pas le but du post ;-)
PS2: c'est sur un host en ext4 avec des vm lxc sous btrfs, d'où les e2fs…

-- 
Daniel

Un intellectuel assis va moins loin qu'un con qui marche.
Michel Audiard

Re: Noyaux backport [Re: Cartes graphiques Intel intégrée au CPU et Debian]

2012-01-07 Par sujet Jean-Yves F. Barbier

On Sat, 7 Jan 2012 23:29:14 +0100
GaÃ«tan PERRIER  wrote:

> 
> Je rebondis sur les noyaux

Ca doit faire mal.

> backport pour squeeze. Comment fait-on pour les
> installer vu qu'il manque tous les paquets firmware-* ?

firmware-non-free est dispo dans backports; sinon tu testes si les
packages de sid s'installent, et si ce n'est pas le cas tu extraits
les firmwares et tu les colles dans /lib/firmware

-- 
America, I'm putting my queer shoulder to the wheel.
-- Allen Ginsberg

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120108000806.7fd1eee9@anubis.defcon1

Noyaux backport [Re: Cartes graphiques Intel intégrée au CPU et Debian]

2012-01-07 Par sujet Gaëtan PERRIER

Le Sat, 07 Jan 2012 18:07:53 +0100
Steve B  a écrit:


> Bonjour,
> 
> Il me semble que les IGP des processeurs SandyBridge (i3, i5 et i7 
> 2XXX), ne sont supportés qu'à partir du noyau 3. Donc à voir avec les 
> noyaux disponibles pour Squeeze (éventuellement en backport).
> La partie CPU est supportée sans problème et fonctionnera avec une carte 
> graphique séparée sinon.
> 

Je rebondis sur les noyaux backport pour squeeze. Comment fait-on pour les
installer vu qu'il manque tous les paquets firmware-* ?

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120107232914.9de44744ef08bd01f318d...@neuf.fr

Re: [RESOLU] Backport etch. Où sont-ils ?

2010-09-11 Par sujet Guy Roussin


Bonjour,

Finalement je viens de trouver, la réponse est :
deb http://archive.debian.org/backports.org etch-backports main

La réponse m'est apparu lorsque j'ai voulu ouvrir un bug...
La réponse a ma question se trouvait dans les archives.
http://lists.debian.org/debian-backports/2010/09/msg00030.html

Merci à ceux qui se sont intéressés à mon problème ...

Guy

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8b990e.2070...@teledetection.fr

Re: Backport etch. Où sont-ils ?

2010-09-10 Par sujet Serge Cavailles

Bonjour,

Le Friday 10 September 2010 20:38:14 Guy Roussin, vous avez écrit :
> Sur cette page je lis :
> "Downloads will still be available, but every user is recommended to update
> to Debian Lenny / lenny-backports."
> Ok, y a plus d'upgrade (uploads) mais normalement les paquets doivent
> encore être accessibles ?

Il existe le service http://snapshot.debian.org/, une machine à remonter le 
temps qui permet d'accéder à d'anciens paquets en fonction d'une date ou d'un 
numéro de version.

L'annonce du service:   http://www.debian.org/News/2010/20100412

Ça ne procure sans doute pas les mêmes facilités qu'un dépôt, mais vous 
devriez néanmoins pouvoir y trouver les paquets souhaités.

Si ça peut aider :)

-- 
Serge

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201009102137.38185.debse...@free.fr

Re: Backport etch. O ù sont-ils ?

2010-09-10 Par sujet JF Straeten


Re,

On Fri, Sep 10, 2010 at 08:38:14PM +0200, Guy Roussin wrote:

> >>Merci, effectivement on dirait qu'ils y sont mais il doit y avoir quelque 
> >>chose
> >>de pas carré au niveau des serveurs ?
> >[...]
> >
> >http://backports.debian.org/news/etch_backports_discontinued/
> >
> Sur cette page je lis :
> "Downloads will still be available, but every user is recommended to
> update to Debian Lenny / lenny-backports."

> Ok, y a plus d'upgrade (uploads) mais normalement les paquets
> doivent encore être accessibles ?

Il me semble aussi. (Sinon, pourquoi laisser les paquets sur le
serveur ?)

Le lien donné fonctionne avec les backports lenny en tout cas.

A+

-- 

JFS.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100910190735.ga13...@hohenhole.jfs.dt

Re: Backport etch. Où sont-ils ?

2010-09-10 Par sujet Guy Roussin


Merci, effectivement on dirait qu'ils y sont mais il doit y avoir quelque chose
de pas carré au niveau des serveurs ?

[...]

http://backports.debian.org/news/etch_backports_discontinued/


Sur cette page je lis :
"Downloads will still be available, but every user is recommended to update to Debian 
Lenny / lenny-backports."

Ok, y a plus d'upgrade (uploads) mais normalement les paquets doivent encore 
être
accessibles ?

Guy

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8a7b16.8030...@teledetection.fr

Re: Backport etch. Où sont-ils ?

2010-09-10 Par sujet didier gaumet

On Fri, 10 Sep 2010 18:41:57 +0200
Guy Roussin  wrote:

> Merci, effectivement on dirait qu'ils y sont mais il doit y avoir quelque 
> chose
> de pas carré au niveau des serveurs ?
[...]

http://backports.debian.org/news/etch_backports_discontinued/

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100910192448.d3a8f60e.didier.gau...@gmail.com

Re: Backport etch. Où sont-ils ?

2010-09-10 Par sujet Guy Roussin




Essaye un peu :

deb http://debian.netcologne.de/debian-backports etch-backports main contrib 
non-free


De bonne foi (ils semblent encore là), mais sans certitude (pas
vérifié).



Merci, effectivement on dirait qu'ils y sont mais il doit y avoir quelque chose
de pas carré au niveau des serveurs ?

J'obtiens ça sur un aptitude update ou apt update :

W: Impossible de localiser la liste des paquets sources http://debian.netcologne.de 
etch-backports/main Packages 
(/var/lib/apt/lists/debian.netcologne.de_debian-backports_dists_etch-backports_main_binary-amd64_Packages) 
- stat (2 Aucun fichier ou répertoire de ce type)
W: Impossible de localiser la liste des paquets sources http://debian.netcologne.de 
etch-backports/contrib Packages 
(/var/lib/apt/lists/debian.netcologne.de_debian-backports_dists_etch-backports_contrib_binary-amd64_Packages) 
- stat (2 Aucun fichier ou répertoire de ce type)
W: Impossible de localiser la liste des paquets sources http://debian.netcologne.de 
etch-backports/non-free Packages 
(/var/lib/apt/lists/debian.netcologne.de_debian-backports_dists_etch-backports_non-free_binary-amd64_Packages) 
- stat (2 Aucun fichier ou répertoire de ce type)

W: Vous pouvez lancer « apt-get update » pour corriger ces problèmes.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8a5fd5.5030...@teledetection.fr

Re: Backport etch. O ù sont-ils ?

2010-09-10 Par sujet JF Straeten


Re,

On Fri, Sep 10, 2010 at 06:27:26PM +0200, Guy Roussin wrote:

> J'ai un serveur en etch (amd64) qui utilise quelques paquets
> provenant des etch backports ... Il semble que suite à la migration
> vers debian.org les paquets etch backports aient disparus ... Je
> cherche un dépôt mirroir de ces backports pour etch.

Essaye un peu :

deb http://debian.netcologne.de/debian-backports etch-backports main contrib 
non-free


De bonne foi (ils semblent encore là), mais sans certitude (pas
vérifié).

Hih,


-- 

JFS.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100910163338.ga13...@hohenhole.jfs.dt

Backport etch. Où sont-ils ?

2010-09-10 Par sujet Guy Roussin


Bonjour,

J'ai un serveur en etch (amd64) qui utilise quelques paquets
provenant des etch backports ...
Il semble que suite à la migration vers debian.org les paquets
etch backports aient disparus ... Je cherche un dépôt mirroir
de ces backports pour etch.

Merci.

--
Guy Roussin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8a5c6e.4030...@teledetection.fr

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-06 Par sujet giggz

Le 06/08/2010 09:43, Pascal Hambourg a écrit :
> giggzounet a écrit :
>>
>> d apres le man que j ai sous la main:
>> ethtool -K--offload ethX [rx on|off] [tx on|off] [sg on|off] [tso
>> on|off] [ufo on|off] [gso on|off]
>>
>> donc en gros je mets tout a off ?
> 
> Oui, et si ça remarche tu remets à les options à on une par une pour
> trouver celle qui foire, ou la combinaison d'options qui foire.
> 

bon j'ai essayé sous debian lenny avec le 2.6.32 et le module du noyau
atl1c:
- ethtool -k eth0 donne:
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: on
large receive offload: off

- seul ethtool -K eth0 sg off gso off fontionnent. pour tous les autres
paramètres j'ai droit à "Operation not supported".

- avec ethtool -K eth0 sg off gso off le problème reste le même. a
savoir avec une mtu de 1492 et tcp_timestamps=0 pas de download possible
depuis le NAS.


J'ai aussi essayé sous backtrack 4 avec le 2.6.30.9 et le module atl1e.
exactement les mêmes résultats.

Enfin j'ai testé sur debian lenny avec le noyau 2.6.32 de backport et le
dernier module atl1e d'atheros et j'ai encore exactement les mêmes
résultats.

J'ai regardé du côté du NAS si je pouvais faire la même chose avec
ethtool. mais non je ne peux pas. j'ai bien ethtool mais en version
1.3...c'est vieux!

Merci! et bon we

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i3h49m$1k...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-06 Par sujet giggzounet

Le 06/08/2010 09:43, Pascal Hambourg a écrit :
> giggzounet a écrit :
>>
>> d apres le man que j ai sous la main:
>> ethtool -K--offload ethX [rx on|off] [tx on|off] [sg on|off] [tso
>> on|off] [ufo on|off] [gso on|off]
>>
>> donc en gros je mets tout a off ?
> 
> Oui, et si ça remarche tu remets à les options à on une par une pour
> trouver celle qui foire, ou la combinaison d'options qui foire.
> 

ok.

>> D'apres toi, ai je assez d'éléments pour faire un rapport de bug pour le
>> noyau sur le tracker debian ?
> 
> Je pense, oui.
> Au fait, le problème ne se produit qu'avec le NAS et pas lors de
> transferts depuis d'autres machines du LAN ou l'extérieur (sinon je
> suppose que tu en aurais parlé) ?
> 

- avec le NAS ftp/cifs et NFS foirent.

- sur mon LAN j ai aussi un serveur de fichiers qui tourne sous debian
lenny. J'exporte les dossier via NFS. Entre mon eeepc et ce serveur de
fichiers je n experimente aucun probleme (je n'ai  pas de ftp ou de
samba). Evidemment le harware est different. La chose vraiment
différente est que sur le NAS la carte est capable de faire du gigabit.
Mais bon mon routeur n'est pas gigabit...

- Entre mon eeepc et mon autre laptop sous sid je fais du rsync a
travers du ssh et je n ai aucun probleme. bon parfois l'eeepc
freeze...mais ca c'est un probleme 'connu' sur le 1201n. c'est peut etre
lié, je n'en sais rien.

- qd je télécharge des fichiers depuis le net sur l'eeepc je n'ai pas
exprimenté de probleme pour l'instant.



-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i3gf7d$q3...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-06 Par sujet Pascal Hambourg

giggzounet a écrit :
> 
> d apres le man que j ai sous la main:
> ethtool -K--offload ethX [rx on|off] [tx on|off] [sg on|off] [tso
> on|off] [ufo on|off] [gso on|off]
> 
> donc en gros je mets tout a off ?

Oui, et si ça remarche tu remets à les options à on une par une pour
trouver celle qui foire, ou la combinaison d'options qui foire.

> D'apres toi, ai je assez d'éléments pour faire un rapport de bug pour le
> noyau sur le tracker debian ?

Je pense, oui.
Au fait, le problème ne se produit qu'avec le NAS et pas lors de
transferts depuis d'autres machines du LAN ou l'extérieur (sinon je
suppose que tu en aurais parlé) ?

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c5bbd17.9060...@plouf.fr.eu.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-06 Par sujet giggzounet

Le 06/08/2010 09:08, giggzounet a écrit :
> Le 06/08/2010 00:15, Pascal Hambourg a écrit :
>> giggz a écrit :
>>>
>>> sous backtrack 4 j'ai exactement le même comportement que sous debian lenny:
>>> MTU=1492 et tcp_timestamps=0 -> bug
>>> MTU=1492 et tcp_timestamps=1 -> ok
>>> MTU=1500 ou tcp_timestamps=0 -> ok
>>> MTU=1500 ou tcp_timestamps=1 -> ok
>>>
>>> Ce n'est vraiment que dans le cas où MTU=1492 et tcp_timestamps=0 que le
>>> bug apparait.
>>

[snip]

en regardant sur google, j ai trouvé via cette url
https://help.ubuntu.com/community/Firestarter ce bug ci:
https://bugs.launchpad.net/ubuntu/+source/firestarter/+bug/258863

ca ressemble étrangement a mon probleme...

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i3gdoh$lh...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-06 Par sujet giggzounet

Le 06/08/2010 00:15, Pascal Hambourg a écrit :
> giggz a écrit :
>>
>> sous backtrack 4 j'ai exactement le même comportement que sous debian lenny:
>> MTU=1492 et tcp_timestamps=0 -> bug
>> MTU=1492 et tcp_timestamps=1 -> ok
>> MTU=1500 ou tcp_timestamps=0 -> ok
>> MTU=1500 ou tcp_timestamps=1 -> ok
>>
>> Ce n'est vraiment que dans le cas où MTU=1492 et tcp_timestamps=0 que le
>> bug apparait.
> 
> Merci pour ce retour.
> 
>> sous sid je n'ai aucun problème quelques soit la mtu ou la valeur de
>> tcp_timestamps. Mais ce n'est pas le même pc et donc pas la même carte
>> graphique et pas le même driver (b44).
> 
> Ah oui, j'avais oublié ce détail.
> Donc a priori le bug existe avec tous les noyaux mais est lié aux
> pilotes atl1*. Ou alors c'est un bug tordu du NAS qui ne se manifeste
> que lorsqu'on communique avec lui à travers ces pilotes.
> Tu as essayé de jouer avec ethtool -k/-K pour désactiver les options
> d'offload ?
> 

non pas encore :) j ai po eu le temps.

d apres le man que j ai sous la main:
ethtool -K--offload ethX [rx on|off] [tx on|off] [sg on|off] [tso
on|off] [ufo on|off] [gso on|off]

donc en gros je mets tout a off ?

D'apres toi, ai je assez d'éléments pour faire un rapport de bug pour le
noyau sur le tracker debian ?

Bonne journée

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i3gcdh$g8...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-05 Par sujet Pascal Hambourg

giggz a écrit :
> 
> sous backtrack 4 j'ai exactement le même comportement que sous debian lenny:
> MTU=1492 et tcp_timestamps=0 -> bug
> MTU=1492 et tcp_timestamps=1 -> ok
> MTU=1500 ou tcp_timestamps=0 -> ok
> MTU=1500 ou tcp_timestamps=1 -> ok
> 
> Ce n'est vraiment que dans le cas où MTU=1492 et tcp_timestamps=0 que le
> bug apparait.

Merci pour ce retour.

> sous sid je n'ai aucun problème quelques soit la mtu ou la valeur de
> tcp_timestamps. Mais ce n'est pas le même pc et donc pas la même carte
> graphique et pas le même driver (b44).

Ah oui, j'avais oublié ce détail.
Donc a priori le bug existe avec tous les noyaux mais est lié aux
pilotes atl1*. Ou alors c'est un bug tordu du NAS qui ne se manifeste
que lorsqu'on communique avec lui à travers ces pilotes.
Tu as essayé de jouer avec ethtool -k/-K pour désactiver les options
d'offload ?

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c5b37f1.4030...@plouf.fr.eu.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-05 Par sujet giggz

Le 04/08/2010 18:13, Pascal Hambourg a écrit :
> giggz a écrit :

>>> les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0.
>>> Est ce normal ?
> 
> Disons que ce ne sont pas les valeurs par défaut du noyau. Ces options
> n'existaient pas lors de la conception initiale de TCP, et si la machine
> en face ne supporte pas l'une d'elle, elle n'est pas utilisée. Elles ont
> essentiellement pour but d'augmenter les performances dans certaines
> circonstances : produit débit*latence élevé, pertes de paquets,
> nombreuses connexions...
> 
>> Bon ça avance!!! si je force via sysctl.conf la valeur de
>> net.ipv4.tcp.timestamps à 1, ça marche parfaitement!!! les 2 autres
>> valeurs tcp_sack et tcp_window_scaling n'ont pas d'influence sur le
>> résultat.
> 
> Tu pouvais tester en modifiant directement la valeur du paramètre du
> noyau en ligne de commande avec
> sysctl -w net.ipv4.tcp_timestamps=1
> (le -w n'est apparemment plus obligatoire pour modifier un paramètre)
> (ou echo 1 > /proc/sys/net/ipv4/tcp_timestamps mais c'est laid)
> d'autant plus que le résultat final au démarrage dépend de l'ordre dans
> lequel firestarter et le script qui applique sysctl.conf sont exécutés.
> 
>> et c'est bien firestarter qui modifie cette valeur:
>> dans /etc/firestarter/sysctl-tuning on a la valeur de
>> net.ipv4.tcp.timestamps forcé à 0.
>>
>> Bon je suppose que si cette variable est forcée à 0 il doit y avoir une
>> bonne raison.
> 
> Certains pare-feu et dispositifs NAT obsolètes ou buggés ne gèrent pas
> correctement ces options, aussi il est parfois nécessaire de les
> désactiver. Sinon je ne vois pas trop.
> 
>> je suppose que le rapport de bug doit plutot aller au
>> maintenant du driver atl1c, non ?
> 
> Je vais encore te donner du travail, mais pourrais-tu vérifier si
> tcp_timestamps est à 1 et si le mettre à 0 provoque le problème en
> fonction du MTU avec les autres distributions installées sur la machine
> (sid, backtrack) ? Je pense que ça permettrait de mieux cerner le bug.
> En gros vérifier sur chacune si (si j'ai bien compris) :
> - MTU=1492 et tcp_timestamps=0 -> bug
> - MTU=1500 ou tcp_timestamps=1 -> ok
> 

sous backtrack 4 j'ai exactement le même comportement que sous debian lenny:
MTU=1492 et tcp_timestamps=0 -> bug
MTU=1492 et tcp_timestamps=1 -> ok
MTU=1500 ou tcp_timestamps=0 -> ok
MTU=1500 ou tcp_timestamps=1 -> ok

Ce n'est vraiment que dans le cas où MTU=1492 et tcp_timestamps=0 que le
bug apparait.

sous sid je n'ai aucun problème quelques soit la mtu ou la valeur de
tcp_timestamps. Mais ce n'est pas le même pc et donc pas la même carte
graphique et pas le même driver (b44).

Bonne soirée
Guillaume

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i3fcdf$4c...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-05 Par sujet giggzounet

Le 04/08/2010 18:13, Pascal Hambourg a écrit :
> giggz a écrit :

>>> les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0.
>>> Est ce normal ?
> 
> Disons que ce ne sont pas les valeurs par défaut du noyau. Ces options
> n'existaient pas lors de la conception initiale de TCP, et si la machine
> en face ne supporte pas l'une d'elle, elle n'est pas utilisée. Elles ont
> essentiellement pour but d'augmenter les performances dans certaines
> circonstances : produit débit*latence élevé, pertes de paquets,
> nombreuses connexions...
> 
>> Bon ça avance!!! si je force via sysctl.conf la valeur de
>> net.ipv4.tcp.timestamps à 1, ça marche parfaitement!!! les 2 autres
>> valeurs tcp_sack et tcp_window_scaling n'ont pas d'influence sur le
>> résultat.
> 
> Tu pouvais tester en modifiant directement la valeur du paramètre du
> noyau en ligne de commande avec
> sysctl -w net.ipv4.tcp_timestamps=1
> (le -w n'est apparemment plus obligatoire pour modifier un paramètre)
> (ou echo 1 > /proc/sys/net/ipv4/tcp_timestamps mais c'est laid)
> d'autant plus que le résultat final au démarrage dépend de l'ordre dans
> lequel firestarter et le script qui applique sysctl.conf sont exécutés.
> 

firestarter a toutjours le dernier mot malheureusement. Une possibilité
est de modifier a la main le fichier sysctl-tuning de firestarter...mais
c est po tres satisfaisant.

>> et c'est bien firestarter qui modifie cette valeur:
>> dans /etc/firestarter/sysctl-tuning on a la valeur de
>> net.ipv4.tcp.timestamps forcé à 0.
>>
>> Bon je suppose que si cette variable est forcée à 0 il doit y avoir une
>> bonne raison.
> 
> Certains pare-feu et dispositifs NAT obsolètes ou buggés ne gèrent pas
> correctement ces options, aussi il est parfois nécessaire de les
> désactiver. Sinon je ne vois pas trop.
> 
>> je suppose que le rapport de bug doit plutot aller au
>> maintenant du driver atl1c, non ?
> 
> Je vais encore te donner du travail, mais pourrais-tu vérifier si
> tcp_timestamps est à 1 et si le mettre à 0 provoque le problème en
> fonction du MTU avec les autres distributions installées sur la machine
> (sid, backtrack) ? Je pense que ça permettrait de mieux cerner le bug.
> En gros vérifier sur chacune si (si j'ai bien compris) :
> - MTU=1492 et tcp_timestamps=0 -> bug
> - MTU=1500 ou tcp_timestamps=1 -> ok
> 
> En tout cas ce nouvel élément ne m'éclaire pas quant à la cause du bug.
> 

bon je teste ca des que je suis sur mon LAN.

ce que je peux te dire direct c'est que sous backtrack 4 les valeurs
sont a 1 et la mtu a 1492 et que ca marche.

Merci!

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i3do84$8d...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-04 Par sujet Pascal Hambourg

giggz a écrit :
>>>
>> les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0.
>> Est ce normal ?

Disons que ce ne sont pas les valeurs par défaut du noyau. Ces options
n'existaient pas lors de la conception initiale de TCP, et si la machine
en face ne supporte pas l'une d'elle, elle n'est pas utilisée. Elles ont
essentiellement pour but d'augmenter les performances dans certaines
circonstances : produit débit*latence élevé, pertes de paquets,
nombreuses connexions...

> Bon ça avance!!! si je force via sysctl.conf la valeur de
> net.ipv4.tcp.timestamps à 1, ça marche parfaitement!!! les 2 autres
> valeurs tcp_sack et tcp_window_scaling n'ont pas d'influence sur le
> résultat.

Tu pouvais tester en modifiant directement la valeur du paramètre du
noyau en ligne de commande avec
sysctl -w net.ipv4.tcp_timestamps=1
(le -w n'est apparemment plus obligatoire pour modifier un paramètre)
(ou echo 1 > /proc/sys/net/ipv4/tcp_timestamps mais c'est laid)
d'autant plus que le résultat final au démarrage dépend de l'ordre dans
lequel firestarter et le script qui applique sysctl.conf sont exécutés.

> et c'est bien firestarter qui modifie cette valeur:
> dans /etc/firestarter/sysctl-tuning on a la valeur de
> net.ipv4.tcp.timestamps forcé à 0.
> 
> Bon je suppose que si cette variable est forcée à 0 il doit y avoir une
> bonne raison.

Certains pare-feu et dispositifs NAT obsolètes ou buggés ne gèrent pas
correctement ces options, aussi il est parfois nécessaire de les
désactiver. Sinon je ne vois pas trop.

> je suppose que le rapport de bug doit plutot aller au
> maintenant du driver atl1c, non ?

Je vais encore te donner du travail, mais pourrais-tu vérifier si
tcp_timestamps est à 1 et si le mettre à 0 provoque le problème en
fonction du MTU avec les autres distributions installées sur la machine
(sid, backtrack) ? Je pense que ça permettrait de mieux cerner le bug.
En gros vérifier sur chacune si (si j'ai bien compris) :
- MTU=1492 et tcp_timestamps=0 -> bug
- MTU=1500 ou tcp_timestamps=1 -> ok

En tout cas ce nouvel élément ne m'éclaire pas quant à la cause du bug.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c599199.4010...@plouf.fr.eu.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-04 Par sujet giggz


> - Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est
> tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui
> a normalement un certain nombre d'options TCP activées par défaut :
> timestamp, selective ACK, window scaling...

 Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
 logiciels installes. ou sont activees ces options ? est ce que par
 exemple sysctl -a peut aider ?
>>>
>>> Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans
>>> /proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling).
>>>
>>
>> bon je vais regarder ca! je poste ca des que possible.
>>
> 
> les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0.
> Est ce normal ? si ce n'est pas normal comment je fais pour savoir d'où
> ça vient ?
> 

Bon ça avance!!! si je force via sysctl.conf la valeur de
net.ipv4.tcp.timestamps à 1, ça marche parfaitement!!! les 2 autres
valeurs tcp_sack et tcp_window_scaling n'ont pas d'influence sur le
résultat.

 je soupconne firestarter de me modifier tout ca.

et c'est bien firestarter qui modifie cette valeur:
dans /etc/firestarter/sysctl-tuning on a la valeur de
net.ipv4.tcp.timestamps forcé à 0.

Bon je suppose que si cette variable est forcée à 0 il doit y avoir une
bonne raison. je suppose que le rapport de bug doit plutot aller au
maintenant du driver atl1c, non ?

Merci!
Guillaume

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i3bvei$m7...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-04 Par sujet giggz

Le 04/08/2010 09:24, giggzounet a écrit :
> Le 04/08/2010 01:26, Pascal Hambourg a écrit :
>> giggzounet a écrit :
>>> Le 02/08/2010 18:14, Pascal Hambourg a écrit :

 - Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est
 tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui
 a normalement un certain nombre d'options TCP activées par défaut :
 timestamp, selective ACK, window scaling...
>>>
>>> Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
>>> logiciels installes. ou sont activees ces options ? est ce que par
>>> exemple sysctl -a peut aider ?
>>
>> Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans
>> /proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling).
>>
> 
> bon je vais regarder ca! je poste ca des que possible.
> 

les 3 valeurs (tcp_timestamps, tcp_sack, tcp_window_scaling) sont à 0.
Est ce normal ? si ce n'est pas normal comment je fais pour savoir d'où
ça vient ?

>>> je soupconne firestarter de me modifier tout ca.
>>
>> Je ne connais pas, je préfère utiliser mes propres scripts de règles
>> iptables.
>>
> 
> ben je comprends mais qd on n a pas trop envie de se fatiguer... :)
> 
>> De mon côté, j'ai regardé les changelogs du noyau pour le pilote atl1c
>> (qui est assez "jeune", introduit dans le noyau 2.6.29) à la recherche
>> de changements susceptibles d'expliquer la présence du problème avec le
>> noyau 2.6.32 si le MTU est inférieur à 1500 et son absence avec les
>> noyaux 2.6.30.9 et 2.6.34-1 (le MTU est bien à 1492 aussi avec les
>> autres noyaux ?). Sans succès. Je soupçonnais en particulier
>> l'offloading, dont les différentes options sont contrôlables avec
>> ethtool -k/-K, si ça te dit d'essayer de les désactiver...
>>
> 
> De mon coté j ai appris via google l'existence d'un autre driver
> supportant ma carte: celui du site atheros. il est normalement plus
> avancé. j ai donc booté sur mon 2.6.32 et fait un "make install". il
> m'installe un driver du nom de atl1e. mais apparemment c'est normal. le
> atl1e d'atheros supporte en fait les cartes supportées par les drivers
> atl1e et atl1c du noyau linux. Bon après reboot, rmmod du atl1c et
> modprobe du atl1e, j ai bien internet mais le problème demeure! donc ca
> n a pas l air de venir du driver en lui meme.
> 
> J ai oublié de préciser:
> sur backtrack 4 ou je n ai le probleme, c est un 2.6.30.9 avec le module
> atl1e d'atheros.
> 
> Ce soir j essaye avec un vieux noyau 2.6.30 de debian! et je tente des
> bidouille avec ethtool -k/-K.
> 

bon j'ai testé avec le noyau 2.6.26 officiel de lenny avec atl1c
retroporté...et j'ai exactement le même comportement. donc ça n'a pas
l'air de venir de la version du noyau.


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i3btnr$eu...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-04 Par sujet giggzounet

Le 04/08/2010 01:26, Pascal Hambourg a écrit :
> giggzounet a écrit :
>> Le 02/08/2010 18:14, Pascal Hambourg a écrit :
>>>
>>> - Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est
>>> tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui
>>> a normalement un certain nombre d'options TCP activées par défaut :
>>> timestamp, selective ACK, window scaling...
>>
>> Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
>> logiciels installes. ou sont activees ces options ? est ce que par
>> exemple sysctl -a peut aider ?
> 
> Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans
> /proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling).
> 

bon je vais regarder ca! je poste ca des que possible.

>> je soupconne firestarter de me modifier tout ca.
> 
> Je ne connais pas, je préfère utiliser mes propres scripts de règles
> iptables.
> 

ben je comprends mais qd on n a pas trop envie de se fatiguer... :)

> De mon côté, j'ai regardé les changelogs du noyau pour le pilote atl1c
> (qui est assez "jeune", introduit dans le noyau 2.6.29) à la recherche
> de changements susceptibles d'expliquer la présence du problème avec le
> noyau 2.6.32 si le MTU est inférieur à 1500 et son absence avec les
> noyaux 2.6.30.9 et 2.6.34-1 (le MTU est bien à 1492 aussi avec les
> autres noyaux ?). Sans succès. Je soupçonnais en particulier
> l'offloading, dont les différentes options sont contrôlables avec
> ethtool -k/-K, si ça te dit d'essayer de les désactiver...
> 

De mon coté j ai appris via google l'existence d'un autre driver
supportant ma carte: celui du site atheros. il est normalement plus
avancé. j ai donc booté sur mon 2.6.32 et fait un "make install". il
m'installe un driver du nom de atl1e. mais apparemment c'est normal. le
atl1e d'atheros supporte en fait les cartes supportées par les drivers
atl1e et atl1c du noyau linux. Bon après reboot, rmmod du atl1c et
modprobe du atl1e, j ai bien internet mais le problème demeure! donc ca
n a pas l air de venir du driver en lui meme.

J ai oublié de préciser:
sur backtrack 4 ou je n ai le probleme, c est un 2.6.30.9 avec le module
atl1e d'atheros.

Ce soir j essaye avec un vieux noyau 2.6.30 de debian! et je tente des
bidouille avec ethtool -k/-K.

Merci de ton aide!

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i3b4ju$kt...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-03 Par sujet Pascal Hambourg

giggzounet a écrit :
> Le 02/08/2010 18:14, Pascal Hambourg a écrit :
>>
>> - Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est
>> tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui
>> a normalement un certain nombre d'options TCP activées par défaut :
>> timestamp, selective ACK, window scaling...
> 
> Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
> logiciels installes. ou sont activees ces options ? est ce que par
> exemple sysctl -a peut aider ?

Leurs valeurs sont visibles avec sysctl net.ipv4 ou dans
/proc/sys/net/ipv4/ (tcp_timestamps, tcp_sack, tcp_window_scaling).

> je soupconne firestarter de me modifier tout ca.

Je ne connais pas, je préfère utiliser mes propres scripts de règles
iptables.

De mon côté, j'ai regardé les changelogs du noyau pour le pilote atl1c
(qui est assez "jeune", introduit dans le noyau 2.6.29) à la recherche
de changements susceptibles d'expliquer la présence du problème avec le
noyau 2.6.32 si le MTU est inférieur à 1500 et son absence avec les
noyaux 2.6.30.9 et 2.6.34-1 (le MTU est bien à 1492 aussi avec les
autres noyaux ?). Sans succès. Je soupçonnais en particulier
l'offloading, dont les différentes options sont contrôlables avec
ethtool -k/-K, si ça te dit d'essayer de les désactiver...

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c58a59a.3060...@plouf.fr.eu.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet giggzounet

Le 02/08/2010 18:14, Pascal Hambourg a écrit :
> giggz a écrit :
>>
>> En gros voilà ce que j'ai fait :
>> je me connecte sur mon NAS en ftp -p
>> ensuite je me balade dans mes répertoires et lance un get.
>> rien ne se passe.
>> je fais un ctrl+c
>> et encore un autre.
>> puis "bye"
>> et voilà.
> 
> Bon, je ne suis pas le super-expert en analyse de trace TCP/IP, hein.
> Ce que j'ai relevé comme bizarreries ou anomalies :
> 
> 
> - Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est
> tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui
> a normalement un certain nombre d'options TCP activées par défaut :
> timestamp, selective ACK, window scaling...
> 

Je n ai rien modifié a ce niveau la. donc j ai un pb avec un des
logiciels installes. ou sont activees ces options ? est ce que par
exemple sysctl -a peut aider ? je soupconne firestarter de me modifier
tout ca.

Merci

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i38eds$ru...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet Christophe

Le lundi 02 août 2010 à 16:14 +0200, Pascal Hambourg a écrit :
> Christophe a écrit :
> > 
> > Le lundi 02 août 2010 à 13:08 +0200, Pascal Hambourg a écrit :
> >> Non, car même si le MTU est réglé plus bas, une interface ethernet
> >> accepte quand même les trames de 1500 octets (voire plus).
> > 
> > La commande 'ip link set dev  mtu ' tente de régler la MTU pour
> > la couche IP -et- l'interface, qui n'acceptera plus rien au dessus si
> > elle supporte cette MTU en dur.

Auto-correction, dans le cas de l'interface, il ne s'agit pas d'un
réglage de MTU, mais de la taille maximum de trame ethernet.

> 
> MTU = Maximum *Transmit* Unit, donc en émission. Le MRU en réception ne
> devrait pas être affecté.
> 

Potentiellement, si : les deux sont bridés par notre segment ethernet
maximum, qui est paramétré par le pilote en fonction de la MTU choisie
(au moins l'option jumbo frame, si elle est présente).

> > Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur
> > un deuxième (mon portable, avec une Marvell 88E8072).
> > Sur ce dernier, le fait de descendre la MTU de l'interface à 1494
> > l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend
> > et fragmente ses réponses.
> 
> Je suis surpris car d'une part car chez moi ça marche, et d'autre part
> 1495 reste inférieur à la taille du paquet de requête écho (1500) donc
> ce n'est pas cohérent.
> 
Comme le pilote adapte la configuration de la carte en fonction de la
MTU choisie, je soupçonnais ma carte d'avoir des valeurs en dessous de
1500 et des poussières... Je viens de faire le test à l'envers et j'ai
le même comportement que vous (sur une Realtek cette fois-ci).

Il s'agit d'un bug du pilote sky2 (cartes Marvell Yukon) visiblement, à
1494 ou moins il me produit une erreur "sky2 eth0: rx length error:
status 0x5ea0100 length 1510" dans les messages du noyau. Il doit s'agir
d'un problème de gestion des tampons par le pilote ou je ne sais quoi,
la longueur indiquée dépend de la valeur de MTU paramétrée, par paliers
de 8.

Bref, il faut visiblement faire attention à régler tous les MTU de façon
identique si l'on a affaire à du Marvell sur le réseau.




-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1280773383.2901.216.ca...@hp6830s.herblain.cdjh.info

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet giggz

Le 31/07/2010 12:51, giggz a Ã©crit :
> Bonjour,
> 
> derriÃ¨re mon routeur j'ai :
> un NAS
> un laptop
> un eeepc
> 
> le NAS est configurÃ© pour faire du ftp, du cifs et du NFS vers ces
> machines. Chaque machine a une ip fixe attribuÃ©e par le routeur.
> 
> je veux rÃ©cupÃ©rer un fichier situÃ© sur mon NAS Ã  partir de mon eeepc
> sous debian lenny/backport. et Ã§a ne fonctionne pas. Les symptomes sont
> les suivants :
> - je peux me connecter sans problÃ¨me de mon eeepc vers le NAS via ftp,
> cifs ou NFS. je peux lister et me balader dans mes partages. Par contre
> dÃ¨s que j'essaye de rÃ©cupÃ©rer un fichier, le transfert se bloque quelque
> soit le logiciel utilisÃ© (ftp, gftp, NFS+rsync, cifs+rsync). et il me
> transfÃ¨re 12K... :D
> 
> VoilÃ  ce que j'ai tentÃ© :
> - j'ai boutÃ© mon eeepc sous w7. aucun problÃ¨me de transfert via samba.
> - j'ai boutÃ© mon eeepc sous backtrack. aucun problÃ¨me de transfert via ftp.
> - je pensais Ã  une mauvaise configuration du NAS; j'ai donc tentÃ© avec
> mon autre laptop sous SID. aucun problÃ¨me. tout marche : ftp, cifs et NFS.
> - j'ai pensÃ© Ã  un problÃ¨me de droits: les users sont les mÃªmes entre mon
> laptop et mon eeepc...avec les mÃªmes uid.; j'ai tentÃ© de tÃ©lÃ©charger
> dans /tmp...Ã§a ne marche pas. le transfert se bloque toujours aprÃ¨s 12K...
> - j'ai pensÃ© Ã  un problÃ¨me de parefeu. j'ai dÃ©sactivÃ© le parefeu. j'ai
> activÃ© le parefeu en laissant tout ouvert...le problÃ¨me persiste...
> 
> bref je n'y comprends plus rien. Si vous avez des idÃ©es d'oÃ¹ Ã§a peut
> venir...et surtout oÃ¹ chercher...
> 
> j'ai oubliÃ© de prÃ©ciser: j'ai Ã©videmment regarder les logs (messages,
> syslog, auth, user) et rien de rien...
> 

ci joint le fichier obtenu en faisant:
tcpdump -nvi eth0 -host 192.168.0.5 -w capture_NAS_tcpdump.log

merci d'avance
Guillaume
ÃÃÂ²Â¡`Ã§WLÃ
`2^Ã¿ÃºÃ? \e...@Ã!ÃÂ¨Ã¯Ã¿Ã¿ÃºÃqlÂ,NOTIFY * HTTP/1.1
HOST:239.255.255.250:1900
Cache-CoÃWL$-::Ã? \Ã ÃNLÂ¡E,...@@ÂÃÃÂ¨ÃÂ¨ÃÃ'%Â%h`Â°Ã©HÂ¬ÃWLM.<<Ã ÃNLÂ¡Ã? \E,...@@Â¹rÃÂ¨ÃÂ¨'%ÃÃ/eÂÂ%i`ÃTlÂ´ÃWLÂ.66Ã? \Ã ÃNLÂ¡E(...@@ÂÃÃÂ¨ÃÂ¨ÃÃ'%Â%i/eÂPÂ°lIÃWL]Ã°`tÃ ÃNLÂ¡Ã? \ef...@@NQÃÂ¨ÃÂ¨'%ÃÃ/eÂÂ%iPÃfÂ220 ProFTPD 1.3.3rc1 Server (NETGEAR ReadyÃWLÃ¡Ã°66Ã? \Ã ÃNLÂ¡E(...@@ÂÂ²ÃÂ¨ÃÂ¨ÃÃ'%Â%i/eÃPÂ°lÃ°WLa BBÃ? \Ã ÃnlÂ¡e4...@@ÂÂ¥ÃÂ¨ÃÂ¨ÃÃ'%Â%i/eÃPÂ°ÂÂUSER eeepc
Ã°WLF!<<Ã ÃNLÂ¡Ã? \E(j...@@NÂÃÂ¨ÃÂ¨'%ÃÃ/eÃÂ%uPÃkÃÃ°WLÂWWÃ ÃNLÂ¡Ã? \ei...@@NlÃÂ¨ÃÂ¨'%ÃÃ/eÃÂ%uPÃwt331 Password required for eeepc
Ã°WL7Â66Ã? \Ã ÃNLÂ¡E(...@@ÂÂ°ÃÂ¨ÃÂ¨ÃÃ'%Â%u/eÃ²PÂ°kÃÃµWLÃÂGGÃ? \Ã ÃnlÂ¡e9...@@ÂÂÃÂ¨ÃÂ¨ÃÃ'%Â%u/eÃ²PÂ°ÂÂPASS depression
ÃµWLÃ<<Ã ÃNLÂ¡Ã? \E(j...@@NÂÃÂ¨ÃÂ¨'%ÃÃ/eÃ²Â%ÂPÃkÂÃµWLÂ¯Â	PPÃ ÃNLÂ¡Ã? \eb...@@NqÃÂ¨ÃÂ¨'%ÃÃ/eÃ²Â%ÂPÃÂR230 User eeepc logged in
ÃµWLÃºÂ	66Ã? \Ã ÃNLÂ¡E(...@@ÂÂ®ÃÂ¨ÃÂ¨ÃÃ'%Â%Â/fPÂ°kÂ³ÃµWLpÂ 	<<Ã? \Ã ÃnlÂ¡e@@ÂÂ§ÃÂ¨ÃÂ¨ÃÃ'%Â%Â/fPÂ°ÂzSYST
ÃµWLTÂ¡	<<Ã ÃNLÂ¡Ã? \E(j...@@NÂÃÂ¨ÃÂ¨'%ÃÃ/fÂ%ÂPÃkÂÃµWL$Ã	IIÃ ÃNLÂ¡Ã? \E;j...@@NvÃÂ¨ÃÂ¨'%ÃÃ/fÂ%ÂPÃ"215 UNIX Type: L8
ÃµWLÂ¹f
66Ã? \Ã ÃNLÂ¡E(...@@ÂÂ¬ÃÂ¨ÃÂ¨ÃÃ'%Â%Â/fPÂ°kÂÃ·WL4<<Ã? \Ã ÃnlÂ¡e@@ÂÂ¥ÃÂ¨ÃÂ¨ÃÃ'%Â%Â/fPÂ°ÂzPASV
Ã·WLÃ´D`fÃ ÃNLÂ¡Ã? \ex...@@NXÃÂ¨ÃÂ¨'%ÃÃ/fÂ%ÂPÃÃ¤227 Entering Passive Mode (192,168,0,5,39,Ã·WLRE66Ã? \Ã ÃNLÂ¡E(...@@ÂÂªÃÂ¨ÃÂ¨ÃÃ'%Â%Â/fOPÂ°kdÃ·WLÃ¡E::Ã? \Ã ÃNLÂ¡E,4...@@Â;ÃÂ¨ÃÂ¨Ã¦Ã²'?Â}`Â°cWÂ¬Ã·WLÂF<<Ã ÃNLÂ¡Ã? \E,...@@Â¹rÃÂ¨ÃÂ¨'?Ã¦Ã²/Â¬ÂÃ Â}`ÃÂÂÂ´Ã·WLÃF66Ã? \Ã ÃNLÂ¡E(4...@@Â>ÃÂ¨ÃÂ¨Ã¦Ã²'?Â}/Â¬ÂÃ¡PÂ°Â¯nÃ·WLG<<Ã? \Ã ÃnlÂ¡e@@ÂÂ£ÃÂ¨ÃÂ¨ÃÃ'%Â%Â/fOPÂ°ÂzLIST
Ã·WLWÂ`lÃ ÃNLÂ¡Ã? \e^...@@NQÃÂ¨ÃÂ¨'%ÃÃ/fOÂ%ÂPÃzÃ¦150 Opening ASCII mode data connection forÃ·WLÂ`ÂµÃ ÃNLÂ¡Ã? \eÂ§Â...@@/ÃºÃÂ¨ÃÂ¨'?Ã¦Ã²/Â¬ÂÃ¡Â}PÃÂ»Sdrwxrwxrwx   2 nobody   nogroup

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet giggz

Le 02/08/2010 18:14, Pascal Hambourg a écrit :
> giggz a écrit :
>>
>> En gros voilà ce que j'ai fait :
>> je me connecte sur mon NAS en ftp -p
>> ensuite je me balade dans mes répertoires et lance un get.
>> rien ne se passe.
>> je fais un ctrl+c
>> et encore un autre.
>> puis "bye"
>> et voilà.
> 
> Bon, je ne suis pas le super-expert en analyse de trace TCP/IP, hein.
> Ce que j'ai relevé comme bizarreries ou anomalies :
> 
> 
> - Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est
> tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui
> a normalement un certain nombre d'options TCP activées par défaut :
> timestamp, selective ACK, window scaling...
> 
> - Des checksums sont indiqués comme incorrects. Apparemment cela se
> produit avec les segments émis par le client contenant des données et
> ayant le flag P (PSH, Push) activé. Dans cette trace tous les segments
> émis par client avec des données ont le flag P, donc je ne sais pas si
> c'est la présence de données ou le flag P qui provoque ça. Mais ça n'a
> pas l'air de gêner la communication puisque le serveur acquitte ces
> segments. C'est peut-être un faux positif causé par de l'offloading
> (traitement déporté, par exemple segmentation et calcul du checksum) de
> TCP dans l'interface réseau à la place du noyau.
> 
> - Le serveur envoie régulièrement des segments des données avec un
> offset et une longueur aberrants : longueur des données 1444 au lieu de
> 1452 conformément au MSS annoncé par le client, et offset largement
> au-delà de l'offset courant. Cela se produit systématiquement juste
> après la séquence de synchronisation de la connexion de données lorsque
> le transfert nécessite plus d'un segment :
> 
> séquence de synchronisation :
> 
>> 14:25:12 IP (id 17251, proto TCP (6), length 44) client.dat5 > serveur.dat5: 
>> S,  2994688280:2994688280(0) win 5808 
>> 14:25:12 IP (id 0, proto TCP (6), length 44) serveur.dat5 > client.dat5: 
>> S,  658576691:658576691(0) ack 2994688281 win 5840 
>> 14:25:12 IP (id 17252, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
>> .,  ack 1 win 5808
> 
> 2 segments aberrants :
> 
>> 14:25:12 IP (id 24813, proto TCP (6), length 1484) serveur.dat5 > 
>> client.dat5: . 1461:2905(1444) ack 1 win 5840
>> 14:25:12 IP (id 17253, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
>> .,  ack 1 win 5808
>> 14:25:12 IP (id 24815, proto TCP (6), length 1484) serveur.dat5 > 
>> client.dat5: P 4365:5809(1444) ack 1 win 5840
>> 14:25:12 IP (id 17254, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
>> .,  ack 1 win 5808
> 
> Le client répond à chaque fois qu'il attend l'offset 1. Après un délai
> de 3 secondes des segments normaux sont ensuite transmis par le serveur
> et acquittés par le client :
> 
>> 14:25:15 IP (id 24816, proto TCP (6), length 1492) serveur.dat5 > 
>> client.dat5: . 1:1453(1452) ack 1 win 5840
>> 14:25:15 IP (id 17255, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
>> .,  ack 1453 win 8712
>> 14:25:15 IP (id 24817, proto TCP (6), length 1492) serveur.dat5 > 
>> client.dat5: . 1453:2905(1452) ack 1 win 5840
>> 14:25:15 IP (id 17256, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
>> .,  ack 2905 win 11616
>> 14:25:15 IP (id 24818, proto TCP (6), length 1492) serveur.dat5 > 
>> client.dat5: . 2905:4357(1452) ack 1 win 5840
>> 14:25:15 IP (id 17257, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
>> .,  ack 4357 win 14520
>> 14:25:15 IP (id 24819, proto TCP (6), length 1492) serveur.dat5 > 
>> client.dat5: P 4357:5809(1452) ack 1 win 5840
>> 14:25:15 IP (id 17258, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
>> .,  ack 5809 win 17424
> 
> Puis à nouveau un segment aberrant :
> 
>> 14:25:15 IP (id 24821, proto TCP (6), length 1484) serveur.dat5 > 
>> client.dat5: . 7269:8713(1444) ack 1 win 5840
>> 14:25:15 IP (id 17259, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
>> .,  ack 5809 win 17424
> 
> Après un nouveau délai de 6 secondes cette fois, ça repart :
> 
>> 14:25:21 IP (id 24822, proto TCP (6), length 1492) serveur.dat5 > 
>> client.dat5: . 5809:7261(1452) ack 1 win 5840
>> 14:25:21 IP (id 17260, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
>> .,  ack 7261 win 20328
>> 14:25:21 IP (id 24823, proto TCP (6), length 1492) serveur.dat5 > 
>> client.dat5: . 7261:8713(1452) ack 1 win 5840
>> 14:25:21 IP (id 17261, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
>> .,  ack 8713 win 23232
> 
> (Ces délais sont responsables de la lenteur de réception de fichiers qui
> réussissent à passer.)
> 
> Et ça continue, avec des délais en augmentation jusqu'à ce que le client
> perde patience et interrompe le transfert.
> 
> Je n'ai pas d'explication à proposer pour le moment. Il pourrait être
> intéressant de comparer les traces avec les autres machine/distribution
> qui marchent.
> 
> Quelle est la version du noyau de BackTrack ?
> Quel est le type de l'interface réseau de l'Eee PC ?
> 

tout d'abord mer

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet giggz

Le 01/08/2010 23:10, Christophe a écrit :
> Bonjour,
> 
> Le samedi 31 juillet 2010 à 15:06 +0200, giggz a écrit :
>> Le 31/07/2010 14:39, Pascal Hambourg a écrit :
>>> giggz a écrit :

 question de NooB : les login/password en ftp sont en clair. si je
 copie/colle ce que me sort tcpdump, est ce que  mon login/password est
 lisible ?
>>>
>>> Normalement par défaut tcpdump ne fait pas l'analyse du protocole FTP
>>> (wireshark/tshark si en revanche) et n'affiche pas non plus les données
>>> des paquets, seulement les champs des en-têtes. Mais ça dépend peut-être
>>> des versions.
>>>
>>
>> ok. je joins le fichier en question. apparemment je ne vois pas mon mot
>> de passe...c'est déjà ça. dis moi qd même, s'il te plait, si je dois ou
>> non changer mon password ;)
>>
>> En gros voilà ce que j'ai fait :
>> je me connecte sur mon NAS en ftp -p
>> ensuite je me balade dans mes répertoires et lance un get.
>> rien ne se passe.
>> je fais un ctrl+c
>> et encore un autre.
>> puis "bye"
>> et voilà.
>>
>> Merci d'avance
>> Guillaume
> 
> Tes deux machines ne semblent pas avoir la même MTU : 1500 pour ton NAS
> contre 1492 pour ton eeepc. Ca pourrait poser problème si le NAS n'en
> tient pas compte.
> Tu peux vérifier sa valeur avec la commande 'ip link show dev eth0', et
> la régler avec 'ip link set dev eth0 mtu 1500' suivi d'un 'ip route
> flush cache'.
> 

nouveau rebondissement:

j'ai remis ma mtu de mon NAS à 1500. et j'ai tapé les commandes de
christopĥe ci-dessus sur mon eeepc. je me retrouve donc avec une mtu de
1500 et là ça marche parfaitement...

bon la question est maintenant de savoir pourquoi ça marche pas avec une
mtu plus basse...

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i36u25$e8...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet Pascal Hambourg

giggz a écrit :
> 
> En gros voilà ce que j'ai fait :
> je me connecte sur mon NAS en ftp -p
> ensuite je me balade dans mes répertoires et lance un get.
> rien ne se passe.
> je fais un ctrl+c
> et encore un autre.
> puis "bye"
> et voilà.

Bon, je ne suis pas le super-expert en analyse de trace TCP/IP, hein.
Ce que j'ai relevé comme bizarreries ou anomalies :


- Les SYN contiennent le minimum syndical d'options TCP : MSS et c'est
tout. Ce n'est pas anormal, mais c'est un peu étonnant pour un Linux qui
a normalement un certain nombre d'options TCP activées par défaut :
timestamp, selective ACK, window scaling...

- Des checksums sont indiqués comme incorrects. Apparemment cela se
produit avec les segments émis par le client contenant des données et
ayant le flag P (PSH, Push) activé. Dans cette trace tous les segments
émis par client avec des données ont le flag P, donc je ne sais pas si
c'est la présence de données ou le flag P qui provoque ça. Mais ça n'a
pas l'air de gêner la communication puisque le serveur acquitte ces
segments. C'est peut-être un faux positif causé par de l'offloading
(traitement déporté, par exemple segmentation et calcul du checksum) de
TCP dans l'interface réseau à la place du noyau.

- Le serveur envoie régulièrement des segments des données avec un
offset et une longueur aberrants : longueur des données 1444 au lieu de
1452 conformément au MSS annoncé par le client, et offset largement
au-delà de l'offset courant. Cela se produit systématiquement juste
après la séquence de synchronisation de la connexion de données lorsque
le transfert nécessite plus d'un segment :

séquence de synchronisation :

> 14:25:12 IP (id 17251, proto TCP (6), length 44) client.dat5 > serveur.dat5: 
> S,  2994688280:2994688280(0) win 5808 
> 14:25:12 IP (id 0, proto TCP (6), length 44) serveur.dat5 > client.dat5: 
> S,  658576691:658576691(0) ack 2994688281 win 5840 
> 14:25:12 IP (id 17252, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
> .,  ack 1 win 5808

2 segments aberrants :

> 14:25:12 IP (id 24813, proto TCP (6), length 1484) serveur.dat5 > 
> client.dat5: . 1461:2905(1444) ack 1 win 5840
> 14:25:12 IP (id 17253, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
> .,  ack 1 win 5808
> 14:25:12 IP (id 24815, proto TCP (6), length 1484) serveur.dat5 > 
> client.dat5: P 4365:5809(1444) ack 1 win 5840
> 14:25:12 IP (id 17254, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
> .,  ack 1 win 5808

Le client répond à chaque fois qu'il attend l'offset 1. Après un délai
de 3 secondes des segments normaux sont ensuite transmis par le serveur
et acquittés par le client :

> 14:25:15 IP (id 24816, proto TCP (6), length 1492) serveur.dat5 > 
> client.dat5: . 1:1453(1452) ack 1 win 5840
> 14:25:15 IP (id 17255, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
> .,  ack 1453 win 8712
> 14:25:15 IP (id 24817, proto TCP (6), length 1492) serveur.dat5 > 
> client.dat5: . 1453:2905(1452) ack 1 win 5840
> 14:25:15 IP (id 17256, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
> .,  ack 2905 win 11616
> 14:25:15 IP (id 24818, proto TCP (6), length 1492) serveur.dat5 > 
> client.dat5: . 2905:4357(1452) ack 1 win 5840
> 14:25:15 IP (id 17257, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
> .,  ack 4357 win 14520
> 14:25:15 IP (id 24819, proto TCP (6), length 1492) serveur.dat5 > 
> client.dat5: P 4357:5809(1452) ack 1 win 5840
> 14:25:15 IP (id 17258, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
> .,  ack 5809 win 17424

Puis à nouveau un segment aberrant :

> 14:25:15 IP (id 24821, proto TCP (6), length 1484) serveur.dat5 > 
> client.dat5: . 7269:8713(1444) ack 1 win 5840
> 14:25:15 IP (id 17259, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
> .,  ack 5809 win 17424

Après un nouveau délai de 6 secondes cette fois, ça repart :

> 14:25:21 IP (id 24822, proto TCP (6), length 1492) serveur.dat5 > 
> client.dat5: . 5809:7261(1452) ack 1 win 5840
> 14:25:21 IP (id 17260, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
> .,  ack 7261 win 20328
> 14:25:21 IP (id 24823, proto TCP (6), length 1492) serveur.dat5 > 
> client.dat5: . 7261:8713(1452) ack 1 win 5840
> 14:25:21 IP (id 17261, proto TCP (6), length 40) client.dat5 > serveur.dat5: 
> .,  ack 8713 win 23232

(Ces délais sont responsables de la lenteur de réception de fichiers qui
réussissent à passer.)

Et ça continue, avec des délais en augmentation jusqu'à ce que le client
perde patience et interrompe le transfert.

Je n'ai pas d'explication à proposer pour le moment. Il pourrait être
intéressant de comparer les traces avec les autres machine/distribution
qui marchent.

Quelle est la version du noyau de BackTrack ?
Quel est le type de l'interface réseau de l'Eee PC ?

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de s

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet Jean-Yves F. Barbier

Le Mon, 02 Aug 2010 14:44:20 +0200,
Christophe  a écrit :

...
> Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur
> un deuxième (mon portable, avec une Marvell 88E8072).
> Sur ce dernier, le fait de descendre la MTU de l'interface à 1494
> l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend
> et fragmente ses réponses.

J'abonde dans le sens de Pascal: chez moi aussi ça marche sans PB (avec le
temps de réponse qui fait évidemment un bond lors de la fragmentation.)

-- 

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100802164422.1d70d...@anubis.defcon1

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet Pascal Hambourg

Christophe a écrit :
> 
> Le lundi 02 août 2010 à 13:08 +0200, Pascal Hambourg a écrit :
>> Non, car même si le MTU est réglé plus bas, une interface ethernet
>> accepte quand même les trames de 1500 octets (voire plus).
> 
> La commande 'ip link set dev  mtu ' tente de régler la MTU pour
> la couche IP -et- l'interface, qui n'acceptera plus rien au dessus si
> elle supporte cette MTU en dur.

MTU = Maximum *Transmit* Unit, donc en émission. Le MRU en réception ne
devrait pas être affecté.

> Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur
> un deuxième (mon portable, avec une Marvell 88E8072).
> Sur ce dernier, le fait de descendre la MTU de l'interface à 1494
> l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend
> et fragmente ses réponses.

Je suis surpris car d'une part car chez moi ça marche, et d'autre part
1495 reste inférieur à la taille du paquet de requête écho (1500) donc
ce n'est pas cohérent.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c56d2c2.2030...@plouf.fr.eu.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet Christophe

Bonjour,

Le lundi 02 août 2010 à 13:08 +0200, Pascal Hambourg a écrit :
> Christophe a écrit :
> > 
> > Tes deux machines ne semblent pas avoir la même MTU : 1500 pour ton NAS
> > contre 1492 pour ton eeepc. Ca pourrait poser problème si le NAS n'en
> > tient pas compte.
> 
> Non, car même si le MTU est réglé plus bas, une interface ethernet
> accepte quand même les trames de 1500 octets (voire plus).
> 

La commande 'ip link set dev  mtu ' tente de régler la MTU pour
la couche IP -et- l'interface, qui n'acceptera plus rien au dessus si
elle supporte cette MTU en dur. La notion dont tu parles est valide si
tu restreins ta MTU sur des routes, auquel cas l'interface pourra
entendre des paquets plus gros que la MTU assignée à la route en
question. Mais rien ne garantit que l'interface entendra au dessus de la
MTU qui lui est assignée par ip link.

Sous MS Windows, les réglages sont plus clairs : les options avancées de
la carte réseau permettent de régler la MTU "dure" ou la longueur de
trame de l'interface (souvent appelée "jumbo frames", avec des valeurs
discrètes), et 'netsh interface ipv4 show global' t'indique la MTU
utilisée par la pile IP pour cette liaison. Linux règle les deux depuis
la commande 'ip link'.

Exemple : un de mes pc réglé en 1500 effectue un ping -M do -s 1472 sur
un deuxième (mon portable, avec une Marvell 88E8072).
Sur ce dernier, le fait de descendre la MTU de l'interface à 1494
l'empêche d'entendre les requêtes d'écho, alors qu'à 1495 il les entend
et fragmente ses réponses.

Cordialement,

--
Christophe


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1280753060.2924.52.ca...@hp6830s.herblain.cdjh.info

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet Pascal Hambourg

Christophe a écrit :
> 
> Tes deux machines ne semblent pas avoir la même MTU : 1500 pour ton NAS
> contre 1492 pour ton eeepc. Ca pourrait poser problème si le NAS n'en
> tient pas compte.

Non, car même si le MTU est réglé plus bas, une interface ethernet
accepte quand même les trames de 1500 octets (voire plus).

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c56a740.1040...@plouf.fr.eu.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet giggzounet

Le 02/08/2010 11:16, christophe.f...@free.fr a écrit :
> 
> - "giggzounet"  a écrit :
> 
>> bien le bonjour,
>>
>> [snip]
>>
>>>
>>> Non, pas après reboot de tout ce beau monde et si l'arp poisonning
>>> était bien arrêté. Tu pouvais aussi vider les tables ARP à la main
>>> sur les machines Linux : 'ip neigh flush'. La durée de vie du cache
>>> ARP n'est pas très élevée de toute façon, en un quart d'heure les
>>> effets devraient avoir disparus sans aucune action de ta part.
>>>
>>
>> ok. bon zut alors une cause possible en moins... :)
>>
>> As tu vu qqch d etrange dans la sortie de tcpdump que j ai jointe
>> précédemment ?
> 
> Hormis l'incohérence de MTU/MSS, non. Une capture au format pcap
> avec Wireshark serait la bienvenue, après avoir changé ton mot de
> passe bien entendu voire ton login... Tout sera visible.
> Il fait apparaître certains problèmes facilement, en analysant les
> séquences TCP entre autres.
> 

ok. je fais ca ce soir en rentrant. merci

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i362f4$tj...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet christophe . fish


- "giggzounet"  a écrit :

> bien le bonjour,
> 
> [snip]
> 
> > 
> > Non, pas après reboot de tout ce beau monde et si l'arp poisonning
> > était bien arrêté. Tu pouvais aussi vider les tables ARP à la main
> > sur les machines Linux : 'ip neigh flush'. La durée de vie du cache
> > ARP n'est pas très élevée de toute façon, en un quart d'heure les
> > effets devraient avoir disparus sans aucune action de ta part.
> > 
> 
> ok. bon zut alors une cause possible en moins... :)
> 
> As tu vu qqch d etrange dans la sortie de tcpdump que j ai jointe
> précédemment ?

Hormis l'incohérence de MTU/MSS, non. Une capture au format pcap
avec Wireshark serait la bienvenue, après avoir changé ton mot de
passe bien entendu voire ton login... Tout sera visible.
Il fait apparaître certains problèmes facilement, en analysant les
séquences TCP entre autres.

> 
> Merci de ton aide
> 

De rien !

--
Christophe

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/61.3830821280740571074.javamail.r...@spooler2-g27.priv.proxad.net

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet giggzounet

bien le bonjour,

[snip]

> 
> Non, pas après reboot de tout ce beau monde et si l'arp poisonning
> était bien arrêté. Tu pouvais aussi vider les tables ARP à la main
> sur les machines Linux : 'ip neigh flush'. La durée de vie du cache
> ARP n'est pas très élevée de toute façon, en un quart d'heure les
> effets devraient avoir disparus sans aucune action de ta part.
> 

ok. bon zut alors une cause possible en moins... :)

As tu vu qqch d etrange dans la sortie de tcpdump que j ai jointe
précédemment ?

Merci de ton aide

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i361d7$pr...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet christophe . fish

Bonjour,

- "giggzounet"  a écrit :

> Le 31/07/2010 12:51, giggz a écrit :
> > Bonjour,
> > 
> > derrière mon routeur j'ai :
> > un NAS
> > un laptop
> > un eeepc
> > 
> > le NAS est configuré pour faire du ftp, du cifs et du NFS vers ces
> > machines. Chaque machine a une ip fixe attribuée par le routeur.
> > 
> > je veux récupérer un fichier situé sur mon NAS à partir de mon
> eeepc
> > sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes
> sont
> > les suivants :
> > - je peux me connecter sans problème de mon eeepc vers le NAS via
> ftp,
> > cifs ou NFS. je peux lister et me balader dans mes partages. Par
> contre
> > dès que j'essaye de récupérer un fichier, le transfert se bloque
> quelque
> > soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il
> me
> > transfère 12K... :D
> > 
> > Voilà ce que j'ai tenté :
> > - j'ai bouté mon eeepc sous w7. aucun problème de transfert via
> samba.
> > - j'ai bouté mon eeepc sous backtrack. aucun problème de transfert
> via ftp.
> > - je pensais à une mauvaise configuration du NAS; j'ai donc tenté
> avec
> > mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs
> et NFS.
> > - j'ai pensé à un problème de droits: les users sont les mêmes entre
> mon
> > laptop et mon eeepc...avec les mêmes uid.; j'ai tenté de
> télécharger
> > dans /tmp...ça ne marche pas. le transfert se bloque toujours après
> 12K...
> > - j'ai pensé à un problème de parefeu. j'ai désactivé le parefeu.
> j'ai
> > activé le parefeu en laissant tout ouvert...le problème persiste...
> > 
> > bref je n'y comprends plus rien. Si vous avez des idées d'où ça
> peut
> > venir...et surtout où chercher...
> > 
> > j'ai oublié de préciser: j'ai évidemment regarder les logs
> (messages,
> > syslog, auth, user) et rien de rien...
> > 
> 
> Je me rappelle avoir jouer avec ettercap entre le laptop et le eeepc
> il
> y 2 semaines : j ai lancé ettercap sur le eeepc avec pour cible le
> laptop et j ai fait du arp poisoning pour voir si je récupérais mes
> mot
> de passe (ca marche d ailleurs étonnamment bien). Est ce que ca peut
> avoir une influence ? apres rebooot du routeur, laptop, NAS et eeepc
> ?
> 
> Merci
> 

Non, pas après reboot de tout ce beau monde et si l'arp poisonning
était bien arrêté. Tu pouvais aussi vider les tables ARP à la main
sur les machines Linux : 'ip neigh flush'. La durée de vie du cache
ARP n'est pas très élevée de toute façon, en un quart d'heure les
effets devraient avoir disparus sans aucune action de ta part.

Cordialement,


--
Christophe

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2141829.3826231280739108452.javamail.r...@spooler2-g27.priv.proxad.net

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet giggzounet

Le 02/08/2010 10:17, giggzounet a écrit :
> Le 31/07/2010 12:51, giggz a écrit :
>> Bonjour,
>>
>> derrière mon routeur j'ai :
>> un NAS
>> un laptop
>> un eeepc
>>
>> le NAS est configuré pour faire du ftp, du cifs et du NFS vers ces
>> machines. Chaque machine a une ip fixe attribuée par le routeur.
>>
>> je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc
>> sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont
>> les suivants :
>> - je peux me connecter sans problème de mon eeepc vers le NAS via ftp,
>> cifs ou NFS. je peux lister et me balader dans mes partages. Par contre
>> dès que j'essaye de récupérer un fichier, le transfert se bloque quelque
>> soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me
>> transfère 12K... :D
>>
>> Voilà ce que j'ai tenté :
>> - j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba.
>> - j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp.
>> - je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec
>> mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS.
>> - j'ai pensé à un problème de droits: les users sont les mêmes entre mon
>> laptop et mon eeepc...avec les mêmes uid.; j'ai tenté de télécharger
>> dans /tmp...ça ne marche pas. le transfert se bloque toujours après 12K...
>> - j'ai pensé à un problème de parefeu. j'ai désactivé le parefeu. j'ai
>> activé le parefeu en laissant tout ouvert...le problème persiste...
>>
>> bref je n'y comprends plus rien. Si vous avez des idées d'où ça peut
>> venir...et surtout où chercher...
>>
>> j'ai oublié de préciser: j'ai évidemment regarder les logs (messages,
>> syslog, auth, user) et rien de rien...
>>
> 
> Je me rappelle avoir jouer avec ettercap entre le laptop et le eeepc il
> y 2 semaines : j ai lancé ettercap sur le eeepc avec pour cible le
> laptop et j ai fait du arp poisoning pour voir si je récupérais mes mot
> de passe (ca marche d ailleurs étonnamment bien). Est ce que ca peut
> avoir une influence ? apres rebooot du routeur, laptop, NAS et eeepc ?
> 
> Merci
> 

J'ai aussi fait des tests entre mon eeepc et un fixe qui est aussi sur
mon LAN et je nai aucun probleme pour monter un partage NFS et
telecharger de gros fichiers dessus. Le probleme se concentre donc entre
mon NAS et mon eeepc et uniquement en download (quelque soit la méthode
utilisée: ftp, samba ou nfs).

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i35vc4$jf...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-02 Par sujet giggzounet

Le 31/07/2010 12:51, giggz a écrit :
> Bonjour,
> 
> derrière mon routeur j'ai :
> un NAS
> un laptop
> un eeepc
> 
> le NAS est configuré pour faire du ftp, du cifs et du NFS vers ces
> machines. Chaque machine a une ip fixe attribuée par le routeur.
> 
> je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc
> sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont
> les suivants :
> - je peux me connecter sans problème de mon eeepc vers le NAS via ftp,
> cifs ou NFS. je peux lister et me balader dans mes partages. Par contre
> dès que j'essaye de récupérer un fichier, le transfert se bloque quelque
> soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me
> transfère 12K... :D
> 
> Voilà ce que j'ai tenté :
> - j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba.
> - j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp.
> - je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec
> mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS.
> - j'ai pensé à un problème de droits: les users sont les mêmes entre mon
> laptop et mon eeepc...avec les mêmes uid.; j'ai tenté de télécharger
> dans /tmp...ça ne marche pas. le transfert se bloque toujours après 12K...
> - j'ai pensé à un problème de parefeu. j'ai désactivé le parefeu. j'ai
> activé le parefeu en laissant tout ouvert...le problème persiste...
> 
> bref je n'y comprends plus rien. Si vous avez des idées d'où ça peut
> venir...et surtout où chercher...
> 
> j'ai oublié de préciser: j'ai évidemment regarder les logs (messages,
> syslog, auth, user) et rien de rien...
> 

Je me rappelle avoir jouer avec ettercap entre le laptop et le eeepc il
y 2 semaines : j ai lancé ettercap sur le eeepc avec pour cible le
laptop et j ai fait du arp poisoning pour voir si je récupérais mes mot
de passe (ca marche d ailleurs étonnamment bien). Est ce que ca peut
avoir une influence ? apres rebooot du routeur, laptop, NAS et eeepc ?

Merci

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i35uvb$i8...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-01 Par sujet Jean-Yves F. Barbier

Le Sun, 01 Aug 2010 23:46:33 +0200,
giggz  a écrit :

> Le 01/08/2010 23:39, Jean-Yves F. Barbier a écrit :
> > Le Sun, 01 Aug 2010 23:32:03 +0200,
> > giggz  a écrit :
> > 
> > ...
> >> J'ai mis la valeur de la mtu du NAS à 1492. mais ça ne change rien. De
> >> plsu sur mon laptop la valeur est aussi à 1492 et pourtant tout marche
> >> très bien entre ce laptop et le NAS.
> > 
> > la valeur std pour un LAN est de 1500 bytes.
> > 
> 
> je sais...mais malheureusement mon routeur force la valeur à 1492 au
> moment où il y a dialogue avec le serveur dhcp. En gros si je fonctionne
> en ip fixe je peux forcer la mtu à 1500. mais si je laisse le dhcp faire
> son travail j'ai tjs une mtu à 1492. bon en même temps c'est po très
> grave si tout est à 1492, non ?
 
ça dépend à combien est le router du côté WAN.

c'est une valeur qu'il fallait souvent forcer il-y-a une dizaine d'année,
mais plus maintenant; je me rappelle qu'avec le câble, un déphasage entre
1492 et 1500 pouvait mener jusqu'à -80% de perfs sur le LAN.
en gros, c'est plus rapide de fragmenter.

-- 

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100801235800.53172...@anubis.defcon1

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-01 Par sujet giggz

Le 01/08/2010 23:39, Jean-Yves F. Barbier a écrit :
> Le Sun, 01 Aug 2010 23:32:03 +0200,
> giggz  a écrit :
> 
> ...
>> J'ai mis la valeur de la mtu du NAS à 1492. mais ça ne change rien. De
>> plsu sur mon laptop la valeur est aussi à 1492 et pourtant tout marche
>> très bien entre ce laptop et le NAS.
> 
> la valeur std pour un LAN est de 1500 bytes.
> 

je sais...mais malheureusement mon routeur force la valeur à 1492 au
moment où il y a dialogue avec le serveur dhcp. En gros si je fonctionne
en ip fixe je peux forcer la mtu à 1500. mais si je laisse le dhcp faire
son travail j'ai tjs une mtu à 1492. bon en même temps c'est po très
grave si tout est à 1492, non ?

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i34pvp$qm...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-01 Par sujet Jean-Yves F. Barbier

Le Sun, 01 Aug 2010 23:32:03 +0200,
giggz  a écrit :

...
> J'ai mis la valeur de la mtu du NAS à 1492. mais ça ne change rien. De
> plsu sur mon laptop la valeur est aussi à 1492 et pourtant tout marche
> très bien entre ce laptop et le NAS.

la valeur std pour un LAN est de 1500 bytes.

-- 
Women's Libbers are OK.  I just wouldn't want my sister to marry one.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100801233921.2ef9c...@anubis.defcon1

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-01 Par sujet giggz

Le 01/08/2010 23:10, Christophe a écrit :
> Bonjour,
> 
> Le samedi 31 juillet 2010 à 15:06 +0200, giggz a écrit :
>> Le 31/07/2010 14:39, Pascal Hambourg a écrit :
>>> giggz a écrit :

 question de NooB : les login/password en ftp sont en clair. si je
 copie/colle ce que me sort tcpdump, est ce que  mon login/password est
 lisible ?
>>>
>>> Normalement par défaut tcpdump ne fait pas l'analyse du protocole FTP
>>> (wireshark/tshark si en revanche) et n'affiche pas non plus les données
>>> des paquets, seulement les champs des en-têtes. Mais ça dépend peut-être
>>> des versions.
>>>
>>
>> ok. je joins le fichier en question. apparemment je ne vois pas mon mot
>> de passe...c'est déjà ça. dis moi qd même, s'il te plait, si je dois ou
>> non changer mon password ;)
>>
>> En gros voilà ce que j'ai fait :
>> je me connecte sur mon NAS en ftp -p
>> ensuite je me balade dans mes répertoires et lance un get.
>> rien ne se passe.
>> je fais un ctrl+c
>> et encore un autre.
>> puis "bye"
>> et voilà.
>>
>> Merci d'avance
>> Guillaume
> 
> Tes deux machines ne semblent pas avoir la même MTU : 1500 pour ton NAS
> contre 1492 pour ton eeepc. Ca pourrait poser problème si le NAS n'en
> tient pas compte.
> Tu peux vérifier sa valeur avec la commande 'ip link show dev eth0', et
> la régler avec 'ip link set dev eth0 mtu 1500' suivi d'un 'ip route
> flush cache'.
> 

J'ai mis la valeur de la mtu du NAS à 1492. mais ça ne change rien. De
plsu sur mon laptop la valeur est aussi à 1492 et pourtant tout marche
très bien entre ce laptop et le NAS.

merci!
Bye
GiGGz

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i34p4k$os...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-08-01 Par sujet Christophe

Bonjour,

Le samedi 31 juillet 2010 à 15:06 +0200, giggz a écrit :
> Le 31/07/2010 14:39, Pascal Hambourg a écrit :
> > giggz a écrit :
> >>
> >> question de NooB : les login/password en ftp sont en clair. si je
> >> copie/colle ce que me sort tcpdump, est ce que  mon login/password est
> >> lisible ?
> > 
> > Normalement par défaut tcpdump ne fait pas l'analyse du protocole FTP
> > (wireshark/tshark si en revanche) et n'affiche pas non plus les données
> > des paquets, seulement les champs des en-têtes. Mais ça dépend peut-être
> > des versions.
> > 
> 
> ok. je joins le fichier en question. apparemment je ne vois pas mon mot
> de passe...c'est déjà ça. dis moi qd même, s'il te plait, si je dois ou
> non changer mon password ;)
> 
> En gros voilà ce que j'ai fait :
> je me connecte sur mon NAS en ftp -p
> ensuite je me balade dans mes répertoires et lance un get.
> rien ne se passe.
> je fais un ctrl+c
> et encore un autre.
> puis "bye"
> et voilà.
> 
> Merci d'avance
> Guillaume

Tes deux machines ne semblent pas avoir la même MTU : 1500 pour ton NAS
contre 1492 pour ton eeepc. Ca pourrait poser problème si le NAS n'en
tient pas compte.
Tu peux vérifier sa valeur avec la commande 'ip link show dev eth0', et
la régler avec 'ip link set dev eth0 mtu 1500' suivi d'un 'ip route
flush cache'.

--
Christophe

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1280697039.6184.15.ca...@hp6830s.herblain.cdjh.info

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-07-31 Par sujet giggz

Le 31/07/2010 14:39, Pascal Hambourg a écrit :
> giggz a écrit :
>>
>> question de NooB : les login/password en ftp sont en clair. si je
>> copie/colle ce que me sort tcpdump, est ce que  mon login/password est
>> lisible ?
> 
> Normalement par défaut tcpdump ne fait pas l'analyse du protocole FTP
> (wireshark/tshark si en revanche) et n'affiche pas non plus les données
> des paquets, seulement les champs des en-têtes. Mais ça dépend peut-être
> des versions.
> 

ok. je joins le fichier en question. apparemment je ne vois pas mon mot
de passe...c'est déjà ça. dis moi qd même, s'il te plait, si je dois ou
non changer mon password ;)

En gros voilà ce que j'ai fait :
je me connecte sur mon NAS en ftp -p
ensuite je me balade dans mes répertoires et lance un get.
rien ne se passe.
je fais un ctrl+c
et encore un autre.
puis "bye"
et voilà.

Merci d'avance
Guillaume
14:24:39.874317 IP (tos 0x0, ttl 64, id 46792, offset 0, flags [DF], proto TCP 
(6), length 44) 192.168.0.4.57933 > 192.168.0.5.10021: S, cksum 0x1e6a 
(correct), 2487174152:2487174152(0) win 5808 
14:24:39.874537 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), 
length 44) 192.168.0.5.10021 > 192.168.0.4.57933: S, cksum 0x39f4 (correct), 
619233108:619233108(0) ack 2487174153 win 5840 
14:24:39.874653 IP (tos 0x0, ttl 64, id 46793, offset 0, flags [DF], proto TCP 
(6), length 40) 192.168.0.4.57933 > 192.168.0.5.10021: ., cksum 0x51d1 
(correct), ack 1 win 5808
14:24:39.913398 IP (tos 0x0, ttl 64, id 54843, offset 0, flags [DF], proto TCP 
(6), length 102) 192.168.0.5.10021 > 192.168.0.4.57933: P 1:63(62) ack 1 win 
5840
14:24:39.913523 IP (tos 0x10, ttl 64, id 46794, offset 0, flags [DF], proto TCP 
(6), length 40) 192.168.0.4.57933 > 192.168.0.5.10021: ., cksum 0x5193 
(correct), ack 63 win 5808
14:24:41.039400 IP (tos 0x10, ttl 64, id 46795, offset 0, flags [DF], proto TCP 
(6), length 52) 192.168.0.4.57933 > 192.168.0.5.10021: P, cksum 0x8180 
(incorrect (-> 0xb886), 1:13(12) ack 63 win 5808
14:24:41.039608 IP (tos 0x0, ttl 64, id 54844, offset 0, flags [DF], proto TCP 
(6), length 40) 192.168.0.5.10021 > 192.168.0.4.57933: ., cksum 0x5167 
(correct), ack 13 win 5840
14:24:41.048400 IP (tos 0x0, ttl 64, id 54845, offset 0, flags [DF], proto TCP 
(6), length 73) 192.168.0.5.10021 > 192.168.0.4.57933: P, cksum 0x4201 
(correct), 63:96(33) ack 13 win 5840
14:24:41.048513 IP (tos 0x10, ttl 64, id 46796, offset 0, flags [DF], proto TCP 
(6), length 40) 192.168.0.4.57933 > 192.168.0.5.10021: ., cksum 0x5166 
(correct), ack 96 win 5808
14:24:43.991953 IP (tos 0x10, ttl 64, id 46797, offset 0, flags [DF], proto TCP 
(6), length 54) 192.168.0.4.57933 > 192.168.0.5.10021: P, cksum 0x8182 
(incorrect (-> 0x6891), 13:27(14) ack 96 win 5808
14:24:44.025514 IP (tos 0x0, ttl 64, id 54846, offset 0, flags [DF], proto TCP 
(6), length 40) 192.168.0.5.10021 > 192.168.0.4.57933: ., cksum 0x5138 
(correct), ack 27 win 5840
14:24:44.085207 IP (tos 0x0, ttl 64, id 54847, offset 0, flags [DF], proto TCP 
(6), length 66) 192.168.0.5.10021 > 192.168.0.4.57933: P, cksum 0x70c2 
(correct), 96:122(26) ack 27 win 5840
14:24:44.085331 IP (tos 0x10, ttl 64, id 46798, offset 0, flags [DF], proto TCP 
(6), length 40) 192.168.0.4.57933 > 192.168.0.5.10021: ., cksum 0x513e 
(correct), ack 122 win 5808
14:24:44.085444 IP (tos 0x10, ttl 64, id 46799, offset 0, flags [DF], proto TCP 
(6), length 46) 192.168.0.4.57933 > 192.168.0.5.10021: P, cksum 0x817a 
(incorrect (-> 0x9d78), 27:33(6) ack 122 win 5808
14:24:44.085624 IP (tos 0x0, ttl 64, id 54848, offset 0, flags [DF], proto TCP 
(6), length 40) 192.168.0.5.10021 > 192.168.0.4.57933: ., cksum 0x5118 
(correct), ack 33 win 5840
14:24:44.089889 IP (tos 0x0, ttl 64, id 54849, offset 0, flags [DF], proto TCP 
(6), length 59) 192.168.0.5.10021 > 192.168.0.4.57933: P, cksum 0xe9ac 
(correct), 122:141(19) ack 33 win 5840
14:24:44.127296 IP (tos 0x10, ttl 64, id 46800, offset 0, flags [DF], proto TCP 
(6), length 40) 192.168.0.4.57933 > 192.168.0.5.10021: ., cksum 0x5125 
(correct), ack 141 win 5808
14:24:47.747473 IP (tos 0x10, ttl 64, id 46801, offset 0, flags [DF], proto TCP 
(6), length 46) 192.168.0.4.57933 > 192.168.0.5.10021: P, cksum 0x817a 
(incorrect (-> 0xa075), 33:39(6) ack 141 win 5808
14:24:47.755380 IP (tos 0x0, ttl 64, id 54850, offset 0, flags [DF], proto TCP 
(6), length 89) 192.168.0.5.10021 > 192.168.0.4.57933: P 141:190(49) ack 39 win 
5840
14:24:47.755508 IP (tos 0x10, ttl 64, id 46802, offset 0, flags [DF], proto TCP 
(6), length 40) 192.168.0.4.57933 > 192.168.0.5.10021: ., cksum 0x50ee 
(correct), ack 190 win 5808
14:24:47.755666 IP (tos 0x0, ttl 64, id 13693, offset 0, flags [DF], proto TCP 
(6), length 44) 192.168.0.4.49548 > 192.168.0.5.10099: S, cksum 0xac50 
(correct), 2613432078:2613432078(0) win 5808 
14:24:47.755863 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), 
length 44) 192.168.0.5.10099 > 192.168.0.4.49548: S, cksum 0x5cac (correct), 
617753241:617753241(0) ack 261343207

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-07-31 Par sujet Pascal Hambourg

giggz a écrit :
> 
> question de NooB : les login/password en ftp sont en clair. si je
> copie/colle ce que me sort tcpdump, est ce que  mon login/password est
> lisible ?

Normalement par défaut tcpdump ne fait pas l'analyse du protocole FTP
(wireshark/tshark si en revanche) et n'affiche pas non plus les données
des paquets, seulement les champs des en-têtes. Mais ça dépend peut-être
des versions.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c541988.4010...@plouf.fr.eu.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-07-31 Par sujet giggz

Le 31/07/2010 14:16, Pascal Hambourg a écrit :
> giggz a écrit :
>>
>> Pour la capture j'utilise quoi ? tcpdump ou wireshark ?
> 
> Peu importe, celui que tu sais le mieux utiliser.
> Il y a aussi tshark, la version console de wireshark.
> 
>> quel est le plus
>> simple à utiliser pour qqn qui n'y connait pas grand chose ?
> 
> Probablement wireshark, parce que c'est graphique.
> Mais tcpdump est simple à utiliser pour afficher une trace facile à
> copier à la souris ou à rediriger dans un fichier :
> 
> # tcpdump -ni  host 
> (ctrl+c pour quitter)
> 

ok.
je fais un
tcpdump -nvi eth0 host  > pb_NAS.txt

question de NooB : les login/password en ftp sont en clair. si je
copie/colle ce que me sort tcpdump, est ce que  mon login/password est
lisible ?

Merci :)
Guillaume

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i314rc$3u...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-07-31 Par sujet Pascal Hambourg

Pascal Hambourg a écrit :
> 
> # tcpdump -ni  host 
> (ctrl+c pour quitter)

A la réflexion, l'option -v serait utile pour afficher plus des détails
sur les paquets.

# tcpdump -nvi  host 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c5414bc.9080...@plouf.fr.eu.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-07-31 Par sujet Pascal Hambourg

giggz a écrit :
> 
> Pour la capture j'utilise quoi ? tcpdump ou wireshark ?

Peu importe, celui que tu sais le mieux utiliser.
Il y a aussi tshark, la version console de wireshark.

> quel est le plus
> simple à utiliser pour qqn qui n'y connait pas grand chose ?

Probablement wireshark, parce que c'est graphique.
Mais tcpdump est simple à utiliser pour afficher une trace facile à
copier à la souris ou à rediriger dans un fichier :

# tcpdump -ni  host 
(ctrl+c pour quitter)

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c54142c.9000...@plouf.fr.eu.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-07-31 Par sujet giggz

Le 31/07/2010 13:24, Pascal Hambourg a écrit :
> Salut,
> 
> giggz a écrit :
>>
>> je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc
>> sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont
>> les suivants :
>> - je peux me connecter sans problème de mon eeepc vers le NAS via ftp,
>> cifs ou NFS. je peux lister et me balader dans mes partages. Par contre
>> dès que j'essaye de récupérer un fichier, le transfert se bloque quelque
>> soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me
>> transfère 12K... :D
> 
> Est-ce que le transfert d'un fichier de moins de 12 ko marche ?

oui mais c'est très lent.

> Et dans l'autre sens, est-ce que l'envoi d'un fichier de plus de 12 ko
> marche ?
> 

oui (test avec un fichier de 100Mo) avec un taux de transfert rapide
"normal" pour du 100Mb/s.

>> - j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba.
>> - j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp.
>> - je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec
>> mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS.
> 
> C'est peut-être un problème réseau, au niveau TCP/IP, comme une option
> TCP mal gérée d'un côté ou de l'autre. Quelles versions de noyau sur les
> différentes machines ? Tu pourrais faire une capture de trafic lors d'un
> transfert (en FTP de préférence, c'est plus simple) quand ça marche et
> quand ça bloque pour comparer.
> 

sur le eeepc j'ai une debian lenny + backport. J'ai le dernier kernel de
backport le :
2.6.32-5

sur le laptop j'ai une debian sid avec un 2.6.34.1 compilé à la main.

Pour la capture j'utilise quoi ? tcpdump ou wireshark ? quel est le plus
simple à utiliser pour qqn qui n'y connait pas grand chose ?

Merci
Guillaume

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i312vp$tj...@dough.gmane.org

Re: Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-07-31 Par sujet Pascal Hambourg

Salut,

giggz a écrit :
> 
> je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc
> sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont
> les suivants :
> - je peux me connecter sans problème de mon eeepc vers le NAS via ftp,
> cifs ou NFS. je peux lister et me balader dans mes partages. Par contre
> dès que j'essaye de récupérer un fichier, le transfert se bloque quelque
> soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me
> transfère 12K... :D

Est-ce que le transfert d'un fichier de moins de 12 ko marche ?
Et dans l'autre sens, est-ce que l'envoi d'un fichier de plus de 12 ko
marche ?

> - j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba.
> - j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp.
> - je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec
> mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS.

C'est peut-être un problème réseau, au niveau TCP/IP, comme une option
TCP mal gérée d'un côté ou de l'autre. Quelles versions de noyau sur les
différentes machines ? Tu pourrais faire une capture de trafic lors d'un
transfert (en FTP de préférence, c'est plus simple) quand ça marche et
quand ça bloque pour comparer.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4c540800.3030...@plouf.fr.eu.org

Pb de transfert de fichiers entre un NAS et une debian lenny backport

2010-07-31 Par sujet giggz

Bonjour,

derrière mon routeur j'ai :
un NAS
un laptop
un eeepc

le NAS est configuré pour faire du ftp, du cifs et du NFS vers ces
machines. Chaque machine a une ip fixe attribuée par le routeur.

je veux récupérer un fichier situé sur mon NAS à partir de mon eeepc
sous debian lenny/backport. et ça ne fonctionne pas. Les symptomes sont
les suivants :
- je peux me connecter sans problème de mon eeepc vers le NAS via ftp,
cifs ou NFS. je peux lister et me balader dans mes partages. Par contre
dès que j'essaye de récupérer un fichier, le transfert se bloque quelque
soit le logiciel utilisé (ftp, gftp, NFS+rsync, cifs+rsync). et il me
transfère 12K... :D

Voilà ce que j'ai tenté :
- j'ai bouté mon eeepc sous w7. aucun problème de transfert via samba.
- j'ai bouté mon eeepc sous backtrack. aucun problème de transfert via ftp.
- je pensais à une mauvaise configuration du NAS; j'ai donc tenté avec
mon autre laptop sous SID. aucun problème. tout marche : ftp, cifs et NFS.
- j'ai pensé à un problème de droits: les users sont les mêmes entre mon
laptop et mon eeepc...avec les mêmes uid.; j'ai tenté de télécharger
dans /tmp...ça ne marche pas. le transfert se bloque toujours après 12K...
- j'ai pensé à un problème de parefeu. j'ai désactivé le parefeu. j'ai
activé le parefeu en laissant tout ouvert...le problème persiste...

bref je n'y comprends plus rien. Si vous avez des idées d'où ça peut
venir...et surtout où chercher...

j'ai oublié de préciser: j'ai évidemment regarder les logs (messages,
syslog, auth, user) et rien de rien...

Merci d'avance
Guillaume

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i30v7e$in...@dough.gmane.org

Re: Problème avec dovecot backport & siev e

2010-01-04 Par sujet Jean Baptiste


On 04/01/2010 19:47, Nicolas KOWALSKI wrote:

Jean Baptiste  writes:


Bonsoir,


Bonsoir,


Depuis le passage à Dovecot 1:1.2.9-1~bpo50+1, le plugin Sieve ne
trouve plus les répertoires contenant des accents.

Voici ce que je peux trouver dans les logs:
failed to store into mailbox 'Archives.R&-AOk-seaux': Mailbox doesn't
exist: Archives.R&-AOk-seaux

Le problème est que mes règles précisent bien:
fileinto "Archives.R&AOk-seaux"


Et en mettant le nom du dossier avec l'accent (en utf-8) au lieu de
son équivalent utf-7, ça ne fonctionne pas mieux ?


Hélas non. Je viens de faire le test. Thunderbird n'aime pas du tout :-(
Je vais tester Sieve au cas où.

JB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Problème avec dovecot backport & sieve

2010-01-04 Par sujet Nicolas KOWALSKI

Jean Baptiste  writes:

> Bonsoir,

Bonsoir,

> Depuis le passage à Dovecot 1:1.2.9-1~bpo50+1, le plugin Sieve ne
> trouve plus les répertoires contenant des accents.
>
> Voici ce que je peux trouver dans les logs:
> failed to store into mailbox 'Archives.R&-AOk-seaux': Mailbox doesn't
> exist: Archives.R&-AOk-seaux
>
> Le problème est que mes règles précisent bien:
> fileinto "Archives.R&AOk-seaux"

Et en mettant le nom du dossier avec l'accent (en utf-8) au lieu de
son équivalent utf-7, ça ne fonctionne pas mieux ?

-- 
Nicolas

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Problème avec dovecot backport & si eve

2010-01-04 Par sujet Jean Baptiste


Bonsoir,
Depuis le passage à Dovecot 1:1.2.9-1~bpo50+1, le plugin Sieve ne trouve 
plus les répertoires contenant des accents.


Voici ce que je peux trouver dans les logs:
failed to store into mailbox 'Archives.R&-AOk-seaux': Mailbox doesn't 
exist: Archives.R&-AOk-seaux


Le problème est que mes règles précisent bien:
fileinto "Archives.R&AOk-seaux"

D'autre mails sont bien stockés au bon endroit, y compris depuis 
l'upgrade. Par exemple:

fileinto "Archives.Listes.Linux.Debian.Debian-fr"

J'en déduis donc que le problème vient de l'upgrade, mais je ne trouve 
rien sur le site dovecot.


Si quelqu'un a une idée,
Merci d'avance,
JB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Backport ou pas ?

2009-10-12 Par sujet Charles Plessy

Le Mon, Oct 12, 2009 at 10:52:04PM +0200, Cristian a écrit :
> Le 12/10/09, Charles Plessy a écrit :
> >
> > j'ai jeté un œil à Orca et R, et ils ne posent pas de problème à rétroporter
> > soi-même (après avoir d'abords rétroporté debhelper, python-support et
> > python-louis).
> 
> Juste dans un esprit d'apprentissage, comment as-tu fait pour
> déterminer cela ? Où as-tu été voir et qu'as-tu regardé ?

Comme je n'ai pas machine avec Lenny en ce moment (seulement des hybrides),
j'ai créé un « chroot » Lenny pour compiler des paquets avec sbuild (man
sbuild-createchroot). J'ai ensuite téléchargé le paquet source gnome-orca
(apt-get source) et je l'ai donné à sbuild, qui s'est plaint de l'absence de
python-louis, qui n'a pas pu être compilé sans python-support. Cette partie
aurait aussi pu être faite en inspectant simplement les dépendances de
construction de orca, et en vérifiant qu'elles sont satisfaisables dans Lenny,
mais c'est fastidieux:

aqwa『~』$ apt-cache showsrc gnome-orca | grep Build-Depends
Build-Depends: cdbs, debhelper (>= 5.0.38), autotools-dev, gnome-pkg-tools (>=
0.10), intltool (>= 0.40.0), libbonobo2-dev (>= 2.18.0), libglib2.0-dev (>=
2.10.0), libxml-parser-perl, pkg-config, python-dev (>= 2.4), python-dbus,
python-gnome2-dev, python-gtk2-dev, python-pyatspi, python-pyorbit-dev (>=
2.14.0), python-support (>= 0.5.6), python-louis (>= 1.6.2)

Ceci dit, ça doit être automatisable.

Comme j'avais sbuild sous la main, j'en ai profité pour vérifier que la version
la plus récente de gnome-orca peut bien être compilée. J'avais la flemme de
lire la doc de sbuild, alors j'ai simplement installé python-louis et
python-support dans le chroute (schroot, dpkg -i, apt-get install -f), qui du
coup n'est plus 100 % Lenny. Si tu as de la place sur la machine, c'est
certainement plus simple de compiler directement sur place. Dans ce cas, le
script mk-build-deps du paquet devscripts est ton ami.

Bonne journée,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japon

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Backport ou pas ?

2009-10-12 Par sujet Cristian

Bonjour à tous,

Merci pour vos réponses. Ca avance ! En gros, il semblerait que je
puisse en effet grâce aux backports rester sous Debian pour ce
netbook, du moins avec les 4 progs (Orca, OpenOffice, R et Firefox)
que je veux plus récents sur une stable. Cependant je me pose une
question : quelle serait selon vous la limite raisonnable
d'utilisation des backports ? J'entends par là, s'il commence à me
prendre en plus de ces 4 progs, de vouloir backporter tout gnome ?
Enfin bref, à partir de quel moment pensez-vous qu'il vaut mieux
envisager une autre solution que les backports ? Perso je pense que
vouloir backporter gnome c'est un peu exagéré avec des backports, non
? Ou ça passe sans souci ? C'est histoire de savoir car me connaissant
à ce niveau, quand le nouveau gnome va sortir et que sur ma stable je
verrai un vieux truc que j'utilise pourtant tous les jours et ça va me
pousser à vouloir le mettre à jour vers l'avant-dernière version ou la
dernière quelques mois après sa sortie.

Quelqu'un m'a aussi parlé d'apt-pinning, qui permettrait d'installer
des packquets d'une autre branche sur la stable. Si je commence à
imaginer de mettre à jour gnome, est-ce que cet outil serait plus
approprié que le backportage ou pas ? Ou c'est mieux de passer tout de
suite tout en testing ? :)

En fait tel que je me vois, je vais finir par vouloir mettre à jour
toute la distrib ! :-D Non en fait c'est tout ce qu'on voit et qui
fait la vitrine de GNU/Linux. Ben oui, c'est quand même un Pc qui va
être vu par plein de monde et je ne voudrais pas qu'ils découvrent un
truc à l'air tout vieilli ! Donc euh... mon Ubuntu revient à la
charge... :( mais si les backports... ou l'apt-pinning... :) Bref,
quelles sont les limites de tout cela ? Je rappelle qu'une fois les
paquets mis à jours, je ne veux pas devoir mettre les mains dans le
cambouis pendant des jours pour réparer plein de trucs (notez que
mettre les mains dans le cambuis n'a pas été exclus), ni devoir mettre
à jour 50 trucs par semaine).

Tous vos commentaires sont les bienvenus !

Et en passant ...
Le 12/10/09, Charles Plessy a écrit :
>
> j'ai jeté un œil à Orca et R, et ils ne posent pas de problème à rétroporter
> soi-même (après avoir d'abords rétroporté debhelper, python-support et
> python-louis).

Juste dans un esprit d'apprentissage, comment as-tu fait pour
déterminer cela ? Où as-tu été voir et qu'as-tu regardé ?

encore merci à vous et bonne soirée !

Cristian

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Backport ou pas ?

2009-10-11 Par sujet Charles Plessy

Le Sun, Oct 11, 2009 at 11:07:41PM +0200, Cristian a écrit :
> 
> - Debian avec des backports ? C’est pas un peu trop Orca (qui vient
> avec gnome derrière ?) + OpenOffice + R + Firefox ? Et aussi, qu’en
> est-il de Debian (console et graphique) sur de petits écran 10,1
> pouces ?

Bonjour Cristian,

j'ai jeté un œil à Orca et R, et ils ne posent pas de problème à rétroporter
soi-même (après avoir d'abords rétroporté debhelper, python-support et
python-louis). Debian Lenny paraît donc tout à fait indiquée, avec les
« backports » officiels de OpenOffice.org et Iceweasel.

Amicalement,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Backport ou pas ?

2009-10-11 Par sujet François Boisson

Le Sun, 11 Oct 2009 23:27:06 +0200
Cristian  a écrit:

> A me relire on dirait que mettre à jour tous les 6 mois me gêne. Ce
> n'est bien sûr pas ça, puisque même avec des backports ça sera
> environt tous les 6-7 mois aussi. La différence est qu'avec Ubuntu
> c'est tout qui sera mis à jour. Or, il paraît selon des Debianeux que
> Debian, même en sid est plus stable qu'une Ubuntu alors je me demande
> quoi... :) D'où mon hésitation Debian+backport vs Ubuntu.

Une alternatives est une Debian lenny comme système et un chroot sid
transparent avec des programmes récents: le beurre et la'rgent du beurre pour
500M de librairies supplémentaires...

François Boisson

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Backport ou pas ?

2009-10-11 Par sujet Cristian

Le 11/10/09, Cristian a écrit :
> [... ] Alors qu’avec une Debian
> stable, ben aucun problème ou quasi jamais en tout cas. Mais si je
> dois mettre à jour tous les 6 mois (en un peu décallé par rapport à la
> sortie bien sûr pour qu'il y ait eu des test avant) et n'avoir des
> problèmes que là et après je suis tranquille, je préfère ça que
> risquer d'en avoir toutes les 2 semaines avec une testing + le temps à
> y consacrer.

A me relire on dirait que mettre à jour tous les 6 mois me gêne. Ce
n'est bien sûr pas ça, puisque même avec des backports ça sera
environt tous les 6-7 mois aussi. La différence est qu'avec Ubuntu
c'est tout qui sera mis à jour. Or, il paraît selon des Debianeux que
Debian, même en sid est plus stable qu'une Ubuntu alors je me demande
quoi... :) D'où mon hésitation Debian+backport vs Ubuntu.

Cristian

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Backport ou pas ?

2009-10-11 Par sujet Cristian

Salut à tous,

Ca faisait quelque temps que je n'étais plus passé par ici. Je me suis
acheté un netbook venant avec XP et je souhaite lui mettre Linux en
dual boot. Seulement, sur cet ordi j’ai 2 besoins qui avec Debian
pourraient être incompatibles : stabilité et semi-nouveauté de
quelques programmes clé.

Par stabilité, j’entends qu’il ne faudrait pas que je doive commencer
à souvent bidouiller pour réparer des problèmes suite à des mises à
jours par exemple, vu qu'avec cette machine je serai en déplacement et
en besoin de productivité. Par contre (semi-nouveauté), j’aimerais
disposer d’OpenOffice, d’Orca (le lecteur d’écran pour déficients
visuels), de R (pour les statistiques) et Firefox dans des version pas
trop anciennes, genre à la limite mettre la dernière version mais 2-3
mois après sa sortie pour avoir eu un test par d’autres avant.

Au départ je pensais mettre une testing, compromis entre stabilité et
nouveauté. Cependant j’en ai une sur mon Pc de bureau et je constate
que ça demande un certain temps à y consacrer : il vaut mieux mettre
toutes les dépendances de ce qui arrive à jour sinon on perd le fil
(sauf besoin) et ça devient incohérent dans une testing en constante
évolution, il faut lire les rapports que sort apt-listbug, si on ne
comprend pas il faut aller voir de quoi il s’agit, puis surtout on met
à jour et il peu y avoir des soucis. Et en plus s’il y a un souci, il
faut encore attendre x temps que le correctif passe en testing. Choses
que je ne voudrais pas avoir sur le netbook. Pour un PC pour lequel
j’ai du temps à consacrer, comme le PC de bureau, ça me va très bien,
mais pas pour ce netbook ou je voudrais que les choses soient plus
fluides, moins mouvementées et incertaines et moins « bouffe-temps »
question entretient. En gros, je voudrais mettre à jour et que ça
marche bien dans au moins 90% des cas.

Du coup, j’en arrive à me demander ce qui est mieux pour moi :
- Debian avec des backports ? C’est pas un peu trop Orca (qui vient
avec gnome derrière ?) + OpenOffice + R + Firefox ? Et aussi, qu’en
est-il de Debian (console et graphique) sur de petits écran 10,1
pouces ?
- Ubuntu (Remix ou pas) ? C’est basé Debian donc j’ose le citer ici.
Mais là je me demande si question mises à jour chaotiques de version
en version d’Ubuntu c’est résolu ? Parce qu’avant il était quasi sûr
d’avoir un gros pépin lors d’une migration (du coup on y allait à la
Windows, C.-à-D. qu’on désinstallait puis on installait la version
suivante, ça allait 10 fois plus vite !) Alors qu’avec une Debian
stable, ben aucun problème ou quasi jamais en tout cas. Mais si je
dois mettre à jour tous les 6 mois (en un peu décallé par rapport à la
sortie bien sûr pour qu'il y ait eu des test avant) et n'avoir des
problèmes que là et après je suis tranquille, je préfère ça que
risquer d'en avoir toutes les 2 semaines avec une testing + le temps à
y consacrer.

Perso je me demande si finalement, pour ce netbook (sur mon desktop
restera Debian) Ubuntu ne pourrait pas être une meilleure solution
qu’une Debian avec backport ou qu’une testing.

Si quelqu’un à des avis je suis preneur.

Et je précise que je ne suis pas là pour troller malgré l'évocation
d’Ubuntu dans ce post, ce n’est qu’une question très importante pour
moi en ce moment.

Bonne journée !

Cristian

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Gestion batterie et noyau 2.6.26 backport

2008-09-01 Par sujet Frédéric BOITEUX

Le lun 01 sep 2008 15:37:12 CEST, LEBRETON Philippe
<[EMAIL PROTECTED]> a écrit :

> Bonjour,
> 
> Sur mon Etch, Je viens de mettre à jour mon noyau en 2.6.26 (via
> backport.org) et sous KDE je n'ai plus la gestion de la batterie sur mon
> portable Fujitsu-Siemens lifebook C.
> Avec mon noyau 2.6.24 aucun problème.
> 
> Avez vous une idée?
oui.

Depuis le 2.6.25 je crois, les informations ACPI passant par le
pseudo-fs /proc sont désactivées (elles étaient obsolètes depuis
quelques révisions déjà) au profit de celles disponibles dans /sys.
Alors qu'avec un système récent (Lenny), cela ne pose pas de problème
car les applications ont eu le temps de migrer (quoique ... il y a des
bugs ouverts là-dessus), sur un système Etch, aucune chance d'y
arriver... -> retour au 2.6.24 en attendant...

Fred.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Gestion batterie et noyau 2.6.26 backport

2008-09-01 Par sujet LEBRETON Philippe


Bonjour,

Sur mon Etch, Je viens de mettre à jour mon noyau en 2.6.26 (via 
backport.org) et sous KDE je n'ai plus la gestion de la batterie sur mon 
portable Fujitsu-Siemens lifebook C.

Avec mon noyau 2.6.24 aucun problème.

Avez vous une idée?

J'ai vu dans ls les modules noyau 2.6.26, l'existence dans module 
Fujitsu, a quoi sert-il?

Je n'ai pas trouvé la doc.

Philippe LEBRETON



*
"Le contenu de ce courriel et ses eventuelles pièces jointes sont 
confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet 
envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas 
violer le secret des correspondances, vous ne devez pas le transmettre à d'autres 
personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire.

Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de 
l'altération du présent courriel. Il appartient au destinataire de vérifier que les 
messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues 
dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles 
ne reflètent pas la position de l'Organisme sauf s'il en est disposé autrement dans 
le présent courriel."
**
begin:vcard
fn:LEBRETON  Philippe
n:Philippe;LEBRETON 
org;quoted-printable:CTI Bretagne Pays de Loire;Logistique & R=C3=A9seaux
email;internet:[EMAIL PROTECTED]
title;quoted-printable:Administrateur Syst=C3=A8me
tel;work:02 41 47 77 29
tel;cell:06 30 54 15 55
version:2.1
end:vcard

Gestion batterie et noyau 2.6.26 backport

2008-09-01 Par sujet LEBRETON Philippe


Bonjour,

Sur mon Etch, Je viens de mettre à jour mon noyau en 2.6.26 (via
backport.org) et sous KDE je n'ai plus la gestion de la batterie sur mon
portable Fujitsu-Siemens lifebook C.
Avec mon noyau 2.6.24 aucun problème.

Avez vous une idée?

J'ai vu dans les modules (misc) du noyau 2.6.26, l'existence du module
Fujitsu_laptop, a quoi sert-il?
Je n'ai pas trouvé la doc.

Philippe LEBRETON




*
"Le contenu de ce courriel et ses eventuelles pièces jointes sont 
confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet 
envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas 
violer le secret des correspondances, vous ne devez pas le transmettre à d'autres 
personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire.

Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de 
l'altération du présent courriel. Il appartient au destinataire de vérifier que les 
messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues 
dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles 
ne reflètent pas la position de l'Organisme sauf s'il en est disposé autrement dans 
le présent courriel."
**
begin:vcard
fn:LEBRETON  Philippe
n:Philippe;LEBRETON 
org;quoted-printable:CTI Bretagne Pays de Loire;Logistique & R=C3=A9seaux
email;internet:[EMAIL PROTECTED]
title;quoted-printable:Administrateur Syst=C3=A8me
tel;work:02 41 47 77 29
tel;cell:06 30 54 15 55
version:2.1
end:vcard

Re: Attention, incohérence dans les backport s entre le noyau 2.6.24 et smbfs

2008-06-21 Par sujet guy



Le problème c'est que le smbmount fournit avec etch n'a pas l'air de 
fonctionner avec cifs ... donc grosse galère pour ceux qui comme moi 
font des montages smb à tour de bras ...



Ma machine tourne aussi avec le noyau 2.6.24 des backport, et j'arrive à 
monter des partages windows sans problème, comme ceci:


mount -t cifs -o user=niko,password=secret //serveur/partage /mnt


Ce qui ne marche plus, c'est le smbmount qui permet à un
*utilisateur* de faire des montages smb ...
... pour mount il faut être root.

Guy

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gros soucis avec ssh ( sarge backport )

2007-04-03 Par sujet Raphaël 'SurcouF' Bordet

Le mardi 03 avril 2007 à 13:42 +0200, [EMAIL PROTECTED] a
écrit :
> bonjour,
> 
> lors d'un install ssh s'est désinstallé, mais je n'ay ai
> pas prêté attention ( c'est mal ) ...
> 
> ensuite j'ai eu une coupure de courant et les babasses
> se sont réinitialisées ...
> 
> donc plus de ssh dispo, lkes suels paquet dispos sont :
> 
> openssh-server-udeb - Secure shell server for the Debian installer
> openssh-client-udeb - Secure shell client for the Debian installer
> 
>  paquet non disponible : libnss-files-udeb
> 
> or je ne peut pas les installer du fait des dépendances ...
> 
> pour info j'utilise les paquets rétro portés ...
> c'est très bien quand tout est ok mais là  rontudju [EMAIL PROTECTED] ...
> 
> svp, est il possible d'obtenir ce paquet pour sarge

Tout dépend de ce dont tu disposes dans ton sources.list mais j'aimerais
bien savoir pourquoi tu utilises les paquets openssh backportés ?
Sous Debian sarge, via les dépôts officiels, OpenSSH est fourni via le
paquet « ssh ».

-- 
Raphaël 'SurcouF' Bordet



signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: gros soucis avec ssh ( sarge backport )

2007-04-03 Par sujet Charles Plessy

Le Tue, Apr 03, 2007 at 01:42:33PM +0200, [EMAIL PROTECTED] a écrit :
> 
> openssh-server-udeb - Secure shell server for the Debian installer
> openssh-client-udeb - Secure shell client for the Debian installer
> 
>  paquet non disponible : libnss-files-udeb
> 
> or je ne peut pas les installer du fait des dépendances ...

Bonjour,

comme leur description l'indique, les paquets « udeb » sont destinés à
l'installeur Debian, pas à une Debian déjà installée...

-- 
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

gros soucis avec ssh ( sarge backport )

2007-04-03 Par sujet bernard . schoenacker

bonjour,

lors d'un install ssh s'est désinstallé, mais je n'ay ai
pas prêté attention ( c'est mal ) ...

ensuite j'ai eu une coupure de courant et les babasses
se sont réinitialisées ...

donc plus de ssh dispo, lkes suels paquet dispos sont :

openssh-server-udeb - Secure shell server for the Debian installer
openssh-client-udeb - Secure shell client for the Debian installer

 paquet non disponible : libnss-files-udeb

or je ne peut pas les installer du fait des dépendances ...

pour info j'utilise les paquets rétro portés ...
c'est très bien quand tout est ok mais là  rontudju [EMAIL PROTECTED] ...

svp, est il possible d'obtenir ce paquet pour sarge

et merci patron ( licence IV ) pour la tournée générale

slt
bernard


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Où trouver un backport de librsvg pour Debian sarge ? sinon pensez vous qu'il est difficile d'en créer un (avec toutes les dépendances...) ?

2007-03-03 Par sujet KLEIN Stéphane


Le 01/03/07, François Boisson<[EMAIL PROTECTED]> a écrit :

Le Tue, 27 Feb 2007 10:08:55 +0100
"KLEIN Stéphane" <[EMAIL PROTECTED]> a écrit:

> Bonjour,
>
> j'ai besoin de librsvg pour un serveur en production sous Debian
> Sarge. J'ai cherché le package sur le site "backports.org" mais je ne
> l'ai pas trouvé. J'aimerais savoir si vous avez une idée d'un autre
> site sur lequel je pourrais le trouver ?
>

Bon, je t'ai fait un backport de librsvg pour la sarge, tu trouveras
les paquets sur

http://boisson.homeip.net/sarge/librsvg/

Il y a

librsvg2-dev_2.14.4-2_i386.deb
librsvg2-2_2.14.4-2_i386.deb
librsvg2-common_2.14.4-2_i386.deb
librsvg2-bin_2.14.4-2_i386.deb

Attention, j'ai du modifier un appel d'une fonction g_try_malloc0 pour
rester compatible avec sarge. A priori c'est bon mais bon...


Merci beaucoup.

Re: Où trouver un backport de librsvg pour Debian sarge ? sinon pensez vous qu'il est difficile d'en créer un (avec toutes les dépendances ...) ?

2007-03-01 Par sujet François Boisson

Le Tue, 27 Feb 2007 10:08:55 +0100
"KLEIN Stéphane" <[EMAIL PROTECTED]> a écrit:

> Bonjour,
> 
> j'ai besoin de librsvg pour un serveur en production sous Debian
> Sarge. J'ai cherché le package sur le site "backports.org" mais je ne
> l'ai pas trouvé. J'aimerais savoir si vous avez une idée d'un autre
> site sur lequel je pourrais le trouver ?
> 

Bon, je t'ai fait un backport de librsvg pour la sarge, tu trouveras
les paquets sur

http://boisson.homeip.net/sarge/librsvg/

Il y a

librsvg2-dev_2.14.4-2_i386.deb 
librsvg2-2_2.14.4-2_i386.deb
librsvg2-common_2.14.4-2_i386.deb 
librsvg2-bin_2.14.4-2_i386.deb 

Attention, j'ai du modifier un appel d'une fonction g_try_malloc0 pour
rester compatible avec sarge. A priori c'est bon mais bon...

François Boisson


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: OÃ¹ trouver un backport de librsvg pour Debian sarge ? sinon pensez vous qu'il est difficile d'en crÃ©er un (avec toutes les dÃ©pendances...) ?

2007-03-01 Par sujet bernard . schoenacker

Selon Sylvain Sauvage <[EMAIL PROTECTED]>:

> KLEIN StÃ©phane, mardi 27 fÃ©vrier 2007, 10:08:55 CET
> >
> > Bonjour,
>
> 'jour,
>
> > j'ai besoin de librsvg pour un serveur en production sous Debian
> > Sarge. J'ai cherchÃ© le package sur le site "backports.org" mais je ne
> > l'ai pas trouvÃ©. J'aimerais savoir si vous avez une idÃ©e d'un autre
> > site sur lequel je pourrais le trouver ? [...]
>
>   Pourquoi ne pas directement utiliser les paquets librsvg2-2 et
> librsvg2-common ? Si c'est un problÃšme de version, as-tu essayÃ© de
> rÃ©cupÃ©rer les sources unstable de ces paquets ? Pour cela, tu mets la
> source deb-src de unstable dans ton sources.list et tu rÃ©cupÃšres les
> sources pour chacun des paquets que tu devras recompiler (par un
> dpkg-buildpackage -rfakeroot). Il y a des chances que certaines
> dÃ©pendances soient Ã  reconstruire aussi mais ce n'est pas forcÃ©ment le
> cas : les versions indiquÃ©es dans les dÃ©pendances sont celles avec
> lequel le paquet a Ã©tÃ© construit, pas forcÃ©ment celles qui sont
> nÃ©cessaires.
>   Si tu ne veux pas encombrer ton serveur, tu peux utiliser un chroot
> sur n'importe quelle autre machine (debootstrap pour la crÃ©ation).
>
> --
>  Sylvain Sauvage


bonjour,


voici ce qui est actuellement dispo en paquets :

libimage-rsvg-perl - Perl binding for librsvg
librsvg2-2 - SAX-based renderer library for SVG files. (for GNOME2)
librsvg2-bin - command-line and graphical viewers for SVG files
librsvg2-common - SAX-based renderer library for SVG files. (for GNOME2)
librsvg2-dev - SAX-based renderer library for SVG files. (development files)
librsvg2-ruby - RSVG renderer bindings for the Ruby language



 apt-cache policy librsvg2-common
librsvg2-common:
  Installé : 2.8.1-3
  Candidat : 2.8.1-3
 Table de version :
 *** 2.8.1-3 0
500 http://http.us.debian.org stable/main Packages
500 http://ftp2.fr.debian.org sarge/main Packages
500 http://ftp2.fr.debian.org stable/main Packages
500 ftp://ftp.nerim.net stable/main Packages
500 http://ftp.uni-stuttgart.de stable/main Packages
500 http://ftp.uwa.edu.au stable/main Packages
500 http://ftp.tu-graz.ac.at stable/main Packages
100 /var/lib/dpkg/status
15:56 [EMAIL PROTECTED] ~% apt-cache policy librsvg2-bin
librsvg2-bin:
  Installé : 2.8.1-3
  Candidat : 2.8.1-3
 Table de version :
 *** 2.8.1-3 0
500 http://http.us.debian.org stable/main Packages
500 http://ftp2.fr.debian.org sarge/main Packages
500 http://ftp2.fr.debian.org stable/main Packages
500 ftp://ftp.nerim.net stable/main Packages
500 http://ftp.uni-stuttgart.de stable/main Packages
500 http://ftp.uwa.edu.au stable/main Packages
500 http://ftp.tu-graz.ac.at stable/main Packages
100 /var/lib/dpkg/status
15:56 [EMAIL PROTECTED] ~% apt-cache policy librsvg2-ruby
librsvg2-ruby:
  Installé : 0.12.0-2
  Candidat : 0.12.0-2
 Table de version :
 0.12.0-2 0
500 http://http.us.debian.org stable/main Packages
500 http://ftp2.fr.debian.org sarge/main Packages
500 http://ftp2.fr.debian.org stable/main Packages
500 ftp://ftp.nerim.net stable/main Packages
500 http://ftp.uni-stuttgart.de stable/main Packages
500 http://ftp.uwa.edu.au stable/main Packages
500 http://ftp.tu-graz.ac.at stable/main Packages


slt
bernard


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Où trouver un backport de librsvg pour Debian sarge ? sinon pensez vous qu'il est difficile d'en créer un (avec toutes les dépendances...) ?

2007-03-01 Par sujet Sylvain Sauvage

KLEIN Stéphane, mardi 27 février 2007, 10:08:55 CET
> 
> Bonjour,

'jour,

> j'ai besoin de librsvg pour un serveur en production sous Debian
> Sarge. J'ai cherché le package sur le site "backports.org" mais je ne
> l'ai pas trouvé. J'aimerais savoir si vous avez une idée d'un autre
> site sur lequel je pourrais le trouver ? [...]

  Pourquoi ne pas directement utiliser les paquets librsvg2-2 et
librsvg2-common ? Si c'est un problème de version, as-tu essayé de
récupérer les sources unstable de ces paquets ? Pour cela, tu mets la
source deb-src de unstable dans ton sources.list et tu récupères les
sources pour chacun des paquets que tu devras recompiler (par un
dpkg-buildpackage -rfakeroot). Il y a des chances que certaines
dépendances soient à reconstruire aussi mais ce n'est pas forcément le
cas : les versions indiquées dans les dépendances sont celles avec
lequel le paquet a été construit, pas forcément celles qui sont
nécessaires.
  Si tu ne veux pas encombrer ton serveur, tu peux utiliser un chroot
sur n'importe quelle autre machine (debootstrap pour la création).

-- 
 Sylvain Sauvage

Où trouver un backport de librsvg pour Debian sarge ? sinon pensez vous qu'il est difficile d'en créer un (avec toutes les dépendances...) ?

2007-02-27 Par sujet KLEIN Stéphane


Bonjour,

j'ai besoin de librsvg pour un serveur en production sous Debian
Sarge. J'ai cherché le package sur le site "backports.org" mais je ne
l'ai pas trouvé. J'aimerais savoir si vous avez une idée d'un autre
site sur lequel je pourrais le trouver ?

Si il n'existe pas de backport pour ce package, j'aimerais avoir votre
avis concernant la création de celui-ci. Je connais les bases de la
création de package Debian mais je ne me suis jamais vraiment lancé
dans la création de paquet. Pensez vous que ce premier défi est trop
difficile à cause de toutes les dépendances liées à librsvg ? exemple
des dépendances sous ma Ubuntu : libc6 (>= 2.4-1), libcairo2 (>=
1.2.4), libcroco3 (>= 0.6.1), libfontconfig1 (>= 2.3.0), libfreetype6
(>= 2.2), libglib2.0-0 (>= 2.12.0), libgsf-1-114 (>= 1.14.1),
libgtk2.0-0 (>= 2.10.3), libpango1.0-0 (>= 1.14.5), libpng12-0 (>=
1.2.8rel), libxml2 (>= 2.6.26), zlib1g (>= 1:1.2.1)

Merci d'avance pour votre aide et vos conseils.
Cordialement,
Stéphane

installer noyau backport 2.6.14 snmp

2006-08-30 Par sujet Thierry B


Bonjour,

J'ai une debian sarge avec un noyau 2.6.14 installé de backports.

Je viens de remarquer par un cat /proc/cpuinfo, que j'ai bien le support 
de l'hyperthreading:


$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 4
model name  : Intel(R) Pentium(R) 4 CPU 3.06GHz
stepping: 9
cpu MHz : 3063.107
cache size  : 1024 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm 
pni monitor ds_cpl tm2 cid cx16 xtpr lahf_lm

bogomips: 6125.61

Est-ce que ca vaut vraiment le coup pour un serveur qui fait serveur 
web,mail,ftp,dns et vmware windows d'installer le linux-image 2.6.14 
mais version snmp pour l'hyperthreading niveau performance? ou bien ca 
ne me changera pas grand chose?


Merci :-)

A+


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et

"Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: backport xserver-xorg sur Sarge

2006-04-03 Par sujet steve

Le Lundi, 3 Avril 2006 17.04, NaiosKAE{FR} a écrit :
> steve writes:
> > Le Lundi, 3 Avril 2006 16.52, NaiosKAE{FR} a écrit :
> >> steve writes:
> >> > Le Lundi, 3 Avril 2006 16.44, NaiosKAE{FR} a écrit :
> >> >> steve writes:
> >> >
> >> > [snip]
> >> >
> >> >> > E: Impossible de corriger les problèmes, des paquets défecteux sont
> >> >> > en mode « garder en l'état ».
> >> >>
> >> >> peut etre faut il vérifier quels paquets sont "holdés"
> >> >
> >> > heu... comment je fais ça ?
> >>
> >> dpkg -l | grep ^h
> >
> > j'ai posé la question car j'avais justement fait ça et je n'obtenais
> > aucune réponse... Autre méthode ?
> >
> > Ils sont où ces « paquets défectueux »  tonnerre de Brest ?
>
> a priori pas de paquet holdé

oui

>
> as tu essayé : sudo apt-get install xserver-xorg= 6.9.0.dfsg.1-4
> xserver-common=6.9.0.dfsg.1-4 ?

en fait je crois avoir trouvé la source du problème : le paquet 
xserver-common.

un

aptitude -t sarge-backports install xserver-common

semble résoudre le smilblick.


> tu seras peut être obligé de faire un sudo apt-get -f install avant pour
> revenir à un état stable


je me lance, on verra bien.


PS : je n'utilise plus apt-get mais aptitude, paraît que c'est « mieux » ...


Merci Erwan !

PS 2: Si mon « multipost » marche, je posterais une marche à suivre ici.

-- 
steve
jabber : [EMAIL PROTECTED]

Re: backport xserver-xorg sur Sarge

2006-04-03 Par sujet NaiosKAE{FR}


steve writes:


Le Lundi, 3 Avril 2006 16.52, NaiosKAE{FR} a écrit :

steve writes:
> Le Lundi, 3 Avril 2006 16.44, NaiosKAE{FR} a écrit :
>> steve writes:
>
> [snip]
>
>> > E: Impossible de corriger les problèmes, des paquets défecteux sont en
>> > mode « garder en l'état ».
>>
>> peut etre faut il vérifier quels paquets sont "holdés"
>
> heu... comment je fais ça ?

dpkg -l | grep ^h


j'ai posé la question car j'avais justement fait ça et je n'obtenais aucune
réponse... Autre méthode ?

Ils sont où ces « paquets défectueux »  tonnerre de Brest ?



a priori pas de paquet holdé

as tu essayé : sudo apt-get install xserver-xorg= 6.9.0.dfsg.1-4
xserver-common=6.9.0.dfsg.1-4 ?

tu seras peut être obligé de faire un sudo apt-get -f install avant pour
revenir à un état stable



[snip]

>> > Merci d'avance !
>>
>> A ton service
>
> j'en demande pas tant ;-)

et bien tant pis pour toi ;-o


bon je reviens en arrière : sois à mon service cet après-midi ! ;-)


--
steve
jabber : [EMAIL PROTECTED]






--
 Erwann PENCREACH 
Association At2l pour le logiciel libre
http://www.at2l.net
[EMAIL PROTECTED]

Re: backport xserver-xorg sur Sarge

2006-04-03 Par sujet steve

Le Lundi, 3 Avril 2006 16.52, NaiosKAE{FR} a écrit :
> steve writes:
> > Le Lundi, 3 Avril 2006 16.44, NaiosKAE{FR} a écrit :
> >> steve writes:
> >
> > [snip]
> >
> >> > E: Impossible de corriger les problèmes, des paquets défecteux sont en
> >> > mode « garder en l'état ».
> >>
> >> peut etre faut il vérifier quels paquets sont "holdés"
> >
> > heu... comment je fais ça ?
>
> dpkg -l | grep ^h

j'ai posé la question car j'avais justement fait ça et je n'obtenais aucune 
réponse... Autre méthode ?

Ils sont où ces « paquets défectueux »  tonnerre de Brest ?

>
> [snip]
>
> >> > Merci d'avance !
> >>
> >> A ton service
> >
> > j'en demande pas tant ;-)
>
> et bien tant pis pour toi ;-o

bon je reviens en arrière : sois à mon service cet après-midi ! ;-)


-- 
steve
jabber : [EMAIL PROTECTED]

Re: backport xserver-xorg sur Sarge

2006-04-03 Par sujet NaiosKAE{FR}


steve writes:


Le Lundi, 3 Avril 2006 16.44, NaiosKAE{FR} a écrit :

steve writes:


[snip]


> E: Impossible de corriger les problèmes, des paquets défecteux sont en
> mode « garder en l'état ».

peut etre faut il vérifier quels paquets sont "holdés"


heu... comment je fais ça ?


dpkg -l | grep ^h

[snip]

> Merci d'avance !

A ton service


j'en demande pas tant ;-)


et bien tant pis pour toi ;-o


> --
> steve
> jabber : [EMAIL PROTECTED]


--
steve
jabber : [EMAIL PROTECTED]






--
 Erwann PENCREACH 
Association At2l pour le logiciel libre
http://www.at2l.net
[EMAIL PROTECTED]

Re: backport xserver-xorg sur Sarge

2006-04-03 Par sujet steve

Le Lundi, 3 Avril 2006 16.44, NaiosKAE{FR} a écrit :
> steve writes:

[snip]

> > E: Impossible de corriger les problèmes, des paquets défecteux sont en
> > mode « garder en l'état ».
>
> peut etre faut il vérifier quels paquets sont "holdés"

heu... comment je fais ça ?


> > E: Impossible de corriger les dépendances, certains paquets ne peuvent
> > pas être installés
> > E: Unable to resolve some dependencies!
> > Certains paquets ont des dépendances non résolues. Ceci peut signifier
> > que vous avez demandé une situation impossible ou que vous utilisez la
> > distribution instable qui a besoin de paquets qui n'ont pas encore été
> > créés ou qui ne sont pas encore sortis « d'incoming ».
> >
> > Les paquets suivants ont des dépendances non satisfaites :
> >   xserver-xorg: Dépend: xserver-common (>= 6.9.0.dfsg.1-4bpo1) mais
> > 4.3.0.dfsg.1-14sarge1 est installé
> >
> >
> > Alors comment faire pour obtenir ce fameux xorg ?
>
> etat des xserver apres migration sous etch :
> ii  xserver-common   6.9.0.dfsg.1-4  files
> and utilities common to all X servers
>
> rc  xserver-xfree86  4.3.0.dfsg.1-14sarge1   the
> XFree86 X server
>
> ii  xserver-xorg 6.9.0.dfsg.1-4  the
> X.Org X server
>
> ii  zt-xserver-xgl   1.0.1-1
> zt-xserver-xgl, cvs 20060225
>
>
> pour info sur mon portable j'ai un xserver-xfree86 indiqué comme paquet de
> transition entre xfree86 et xorg.
>
> si ca peut t'aider
>
> > Merci d'avance !
>
> A ton service

j'en demande pas tant ;-)

>
> > --
> > steve
> > jabber : [EMAIL PROTECTED]

-- 
steve
jabber : [EMAIL PROTECTED]

Re: backport xserver-xorg sur Sarge

2006-04-03 Par sujet NaiosKAE{FR}


steve writes:


Bonjour,


Suite à un post que j'avais fait ici sur ce qu'on appelle communément «
multiseat X » (cf.
http://groups.google.ch/group/linux.debian.user.french/browse_thread/thread/fb3e5ab5b76c4937/87aed0e1c231f1d2?q=dlist+clavier&rnum=3#87aed0e1c231f1d2
 )

je m'y suis mis en m'aidant de
http://blog.chris.tylers.info/index.php?/archives/14-Multiseat-X-Under-X11R6.97.0.html
 .

Mon système est une Sarge et comme c'est mon serveur principal, je ne veux pas
passer en testing pour des raisons évidentes de sécurité. Donc je me rabats
sur un backport de xorg.

J'ai donc mis

deb http://www.backports.org/debian/ sarge-backports main

dans mon sources.list, plus


Package: *
Pin: release a=sarge-backports
Pin-Priority: 200


Package: xorg-x11
Pin: release a=sarge-backports
Pin-Priority: 999

dans le fichier preferences. Or, après un

aptitude update

un

aptitude install xserver-xorg

me donne

E: Impossible de corriger les problèmes, des paquets défecteux sont en mode
« garder en l'état ».


peut etre faut il vérifier quels paquets sont "holdés"


E: Impossible de corriger les dépendances, certains paquets ne peuvent pas
être installés
E: Unable to resolve some dependencies!
Certains paquets ont des dépendances non résolues. Ceci peut signifier
que vous avez demandé une situation impossible ou que vous utilisez la
distribution instable qui a besoin de paquets qui n'ont pas encore été créés
ou qui ne sont pas encore sortis « d'incoming ».

Les paquets suivants ont des dépendances non satisfaites :
  xserver-xorg: Dépend: xserver-common (>= 6.9.0.dfsg.1-4bpo1) mais
4.3.0.dfsg.1-14sarge1 est installé


Alors comment faire pour obtenir ce fameux xorg ?


etat des xserver apres migration sous etch :
ii  xserver-common   6.9.0.dfsg.1-4  files
and utilities common to all X servers

rc  xserver-xfree86  4.3.0.dfsg.1-14sarge1   the
XFree86 X server

ii  xserver-xorg 6.9.0.dfsg.1-4  the
X.Org X server

ii  zt-xserver-xgl   1.0.1-1
zt-xserver-xgl, cvs 20060225


pour info sur mon portable j'ai un xserver-xfree86 indiqué comme paquet de
transition entre xfree86 et xorg.

si ca peut t'aider


Merci d'avance !

A ton service



--
steve
jabber : [EMAIL PROTECTED]






--
 Erwann PENCREACH 
Association At2l pour le logiciel libre
http://www.at2l.net
[EMAIL PROTECTED]

backport xserver-xorg sur Sarge

2006-04-03 Par sujet steve

Bonjour,


Suite à un post que j'avais fait ici sur ce qu'on appelle communément « 
multiseat X » (cf. 
http://groups.google.ch/group/linux.debian.user.french/browse_thread/thread/fb3e5ab5b76c4937/87aed0e1c231f1d2?q=dlist+clavier&rnum=3#87aed0e1c231f1d2
 )

je m'y suis mis en m'aidant de 
http://blog.chris.tylers.info/index.php?/archives/14-Multiseat-X-Under-X11R6.97.0.html
 .

Mon système est une Sarge et comme c'est mon serveur principal, je ne veux pas 
passer en testing pour des raisons évidentes de sécurité. Donc je me rabats 
sur un backport de xorg.

J'ai donc mis

deb http://www.backports.org/debian/ sarge-backports main

dans mon sources.list, plus


Package: *
Pin: release a=sarge-backports
Pin-Priority: 200


Package: xorg-x11
Pin: release a=sarge-backports
Pin-Priority: 999

dans le fichier preferences. Or, après un 

aptitude update

un

aptitude install xserver-xorg

me donne 

E: Impossible de corriger les problèmes, des paquets défecteux sont en mode 
« garder en l'état ».
E: Impossible de corriger les dépendances, certains paquets ne peuvent pas 
être installés
E: Unable to resolve some dependencies!
Certains paquets ont des dépendances non résolues. Ceci peut signifier
que vous avez demandé une situation impossible ou que vous utilisez la
distribution instable qui a besoin de paquets qui n'ont pas encore été créés
ou qui ne sont pas encore sortis « d'incoming ».

Les paquets suivants ont des dépendances non satisfaites :
  xserver-xorg: Dépend: xserver-common (>= 6.9.0.dfsg.1-4bpo1) mais 
4.3.0.dfsg.1-14sarge1 est installé


Alors comment faire pour obtenir ce fameux xorg ?

Merci d'avance !


-- 
steve
jabber : [EMAIL PROTECTED]

Backport wordpress 2.0 pour sarge

2006-01-18 Par sujet RoboTux

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bonsoir à tous,

je viens de faire un backport de wordpress 2.0 pour sarge et je n'ai pas
de dépot de paquet chez moi donc voila, si ça intéresse quelqu'un je lui
envoie par mail que ce soit pour sa consommation perso ou pour le mettre
sur un dépot de paquet Debian qu'il aurait.

RoboTux

- --




Ma clé GPG est disponible sur http://www.keyserver.net (0x2B8BE385)

Protégez votre vie privée :
- - Signez/chiffrez vos messages.
Respectez celle des autres :
- - Masquez les destinataires de vos mailings
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDzojRXBAlpiuL44URApv2AJ0V6tnZtUaKfPTAPfdKGTX5vM5eQQCeICj0
P4e4b3qp/RucfUCeqvEHKxg=
=j4df
-END PGP SIGNATURE-


-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: fam backport

2005-12-26 Par sujet mess-mate

François Boisson <[EMAIL PROTECTED]> wrote:
| Le Mon, 19 Dec 2005 11:46:20 +0100
| mess-mate <[EMAIL PROTECTED]> a écrit:
| 
| > Bonjour,
| > quelqu'un pourrait me mettre sur une piste pour un backport de 'fam'
| > pour sarge ?
| > Google ne donne rien :(
| > Merci d'avance
| 
| 
| Je t'ai recompilé fam (unstable) pour sarge, tu trouveras ça sur
| 
| deb http://boisson.homeip.net/sarge/ ./
| 
| François Boisson
| 
| 
| -- 
Merci pour la compilation :)
J'ai cependant pas pû sésoudre le problème.
cordialement

mess-mate   
--
Q:  How do you stop an elephant from charging?
A:  Take away his credit cards.

Re: fam backport

2005-12-19 Par sujet mess-mate

François Boisson <[EMAIL PROTECTED]> wrote:
| Le Mon, 19 Dec 2005 12:43:51 +0100
| Seb <[EMAIL PROTECTED]> a écrit:
| 
| > Quel intérêt d'installer un backport de fam ? Il me semble que le 
| > problème principal de fam (qui "s'emballe" de temps en temps et prend 
| > tout le CPU) n'est pas corrigé ?!?
| 
| Je ne sais pas, il se trouve qu'au moment de lire ce message, je
| travaillais sur la machine où je compile les paquets, ça m'a pris 2
| minutes de faire ce backport (tout est installé pour). Pour le reste, je
| ne vois effectivement pas l'intérêt mais il faut demandé à mess-mate.
| 
Bon, c'est pas résolu.
Voilà ce que j'ai comme erreur:

/usr/lib/libfam.a(Client.o)(.gnu.linkonce.t._ZN5BTreeIiPvE9underflowEPNS1_4NodeEj+0x181):
In function BTree::underflow(BTree::Node*,
unsigned)':
: undefined reference to operator delete(void*)'
/usr/lib/libfam.a(Client.o)(.gnu.linkonce.t._ZN5BTreeIiPvE9underflowEPNS1_4NodeEj+0x270):
In function BTree::underflow(BTree::Node*,
unsigned)':
: undefined reference to operator delete(void*)'
collect2: ld returned 1 exit status
make[3]: *** [maildirkw] Error 1
make[3]: Leaving directory /home/eric/Downl/cone-0.65/maildir'
make[2]: *** [all] Error 2
make[2]: Leaving directory /home/eric/Downl/cone-0.65/maildir'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory /home/eric/Downl/cone-0.65'
make: *** [all] Error 2

( les dernières lignes)



mess-mate   
--
You are wise, witty, and wonderful, but you spend too much time reading
this sort of trash.

Re: fam backport

2005-12-19 Par sujet mess-mate

François Boisson <[EMAIL PROTECTED]> wrote:
| Le Mon, 19 Dec 2005 12:43:51 +0100
| Seb <[EMAIL PROTECTED]> a écrit:
| 
| > Quel intérêt d'installer un backport de fam ? Il me semble que le 
| > problème principal de fam (qui "s'emballe" de temps en temps et prend 
| > tout le CPU) n'est pas corrigé ?!?
| 
| Je ne sais pas, il se trouve qu'au moment de lire ce message, je
| travaillais sur la machine où je compile les paquets, ça m'a pris 2
| minutes de faire ce backport (tout est installé pour). Pour le reste, je
| ne vois effectivement pas l'intérêt mais il faut demandé à mess-mate.
| 
le problème est lié à la version ( peut-être).
J'aimerais essayer 'cone' et la compile s'arrête avec une erreur au
niveau de 'Fam', des fonctions non disponibles...
Je vais essayer cela de suite.
Merci, j'avais ton serveur dans ma sources.list mais commenté, je
sais plus pourquoi.

mess-mate   
--
If you sow your wild oats, hope for a crop failure.

Re: fam backport

2005-12-19 Par sujet François Boisson

Le Mon, 19 Dec 2005 12:43:51 +0100
Seb <[EMAIL PROTECTED]> a écrit:

> Quel intérêt d'installer un backport de fam ? Il me semble que le 
> problème principal de fam (qui "s'emballe" de temps en temps et prend 
> tout le CPU) n'est pas corrigé ?!?

Je ne sais pas, il se trouve qu'au moment de lire ce message, je
travaillais sur la machine où je compile les paquets, ça m'a pris 2
minutes de faire ce backport (tout est installé pour). Pour le reste, je
ne vois effectivement pas l'intérêt mais il faut demandé à mess-mate.

François Boisson


-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: fam backport

2005-12-19 Par sujet Seb


François Boisson a écrit :


Je t'ai recompilé fam (unstable) pour sarge, tu trouveras ça sur

deb http://boisson.homeip.net/sarge/ ./

François Boisson
 

Quel intérêt d'installer un backport de fam ? Il me semble que le 
problème principal de fam (qui "s'emballe" de temps en temps et prend 
tout le CPU) n'est pas corrigé ?!?


Seb


--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: fam backport

2005-12-19 Par sujet François Boisson

Le Mon, 19 Dec 2005 11:46:20 +0100
mess-mate <[EMAIL PROTECTED]> a écrit:

> Bonjour,
> quelqu'un pourrait me mettre sur une piste pour un backport de 'fam'
> pour sarge ?
> Google ne donne rien :(
> Merci d'avance


Je t'ai recompilé fam (unstable) pour sarge, tu trouveras ça sur

deb http://boisson.homeip.net/sarge/ ./

François Boisson


-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

fam backport

2005-12-19 Par sujet mess-mate

Bonjour,
quelqu'un pourrait me mettre sur une piste pour un backport de 'fam'
pour sarge ?
Google ne donne rien :(
Merci d'avance

mess-mate   
--
You have the capacity to learn from mistakes.  You'll learn a lot today.


-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: backport k3b (sid -->etch) problème apt-g et build-dep + dpkg-buildpackage

2005-12-15 Par sujet HEHO

bonsoir,

"k3b is only 0 days old. It must be 10 days old to go in."

donc c'est bien ça hein,
noël.
à plus
hého


-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: backport k3b (sid -->etch) problème apt-get build-dep + dpkg-buildpackage

2005-12-09 Par sujet Philippe Merlin

Bonsoir,
Oui et surtout sur le fait que les deux paquets binutils et mpfr  qui 
bloquaient sa diffusion ont été introduits dans etch aujourd'hui.
A+
Philou75


Le Vendredi 9 Décembre 2005 22:54, HEHO a écrit :
> Le 09.12.2005 16:17, Philippe Merlin exprima :
> > Bonjour,
> > Cela n'engage que moi mais j'ai l'impression que la nouvelle version du
> > gcc-4.0  pour etch va être diffusé prochainement.
> > Alors K3B, digikam, kaffeine + . seront alors disponible, toujours
> > dans mon rêve.
> > A+
> > Philou75
>
> ah..., je crois avoir compris.
> fais-tu allusion à çà :
> "gcc-4.0 is only 5 days old. It must be 10 days old to go in."
> là :
> http://bjorn.haxx.se/debian/testing.pl?package=k3b
> ??
> ou j'ai encore rien compris ?
> à plus.
> hého

Re: backport k3b (sid -->etch) problème apt-g et build-dep + dpkg-buildpackage

2005-12-09 Par sujet HEHO

Le 09.12.2005 16:17, Philippe Merlin exprima :
> Bonjour,
> Cela n'engage que moi mais j'ai l'impression que la nouvelle version du 
> gcc-4.0  pour etch va être diffusé prochainement.
> Alors K3B, digikam, kaffeine + . seront alors disponible, toujours dans 
> mon rêve.
> A+
> Philou75

ah..., je crois avoir compris.
fais-tu allusion à çà :
"gcc-4.0 is only 5 days old. It must be 10 days old to go in."
là :
http://bjorn.haxx.se/debian/testing.pl?package=k3b
??
ou j'ai encore rien compris ?
à plus.
hého


-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: backport k3b (sid -->etch) problème apt-g et build-dep + dpkg-buildpackage

2005-12-09 Par sujet HEHO

Le 09.12.2005 19:31, laurux exprima :
> Essaie ça :
> http://yvesaubry.free.fr/tkcdrecord.php
> Léger et facile !
> Bon, pas aussi complet que k3b mais il fait l'essentiel !
> 
bonsoir,
merci, je vais essayer.
à plus.
hého.


-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: backport k3b (sid -->etch) problème apt-g et build-dep + dpkg-buildpackage

2005-12-09 Par sujet HEHO

Le 09.12.2005 16:17, Philippe Merlin exprima :
> Bonjour,
> Cela n'engage que moi mais j'ai l'impression que la nouvelle version du 
> gcc-4.0  pour etch va être diffusé prochainement.
> Alors K3B, digikam, kaffeine + . seront alors disponible, toujours dans 
> mon rêve.
> A+
> Philou75
ça serait un peu comme noël.
à plus.
hého


-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: backport k3b (sid -->etch) problème apt-get build-dep + dpkg-buildpackage

2005-12-09 Par sujet laurux

Le Fri, 09 Dec 2005 13:50:12 +0100, HEHO a voulu dire :

> Le 08.12.2005 12:40, HEHO exprima :
> > bonjour,
> 
> bon bah, je vais tester xcdroast.
> à plus.
> hého

Essaie ça :
http://yvesaubry.free.fr/tkcdrecord.php
Léger et facile !
Bon, pas aussi complet que k3b mais il fait l'essentiel !

-- 


pgprbre5a4Xi9.pgp
Description: PGP signature

Re: backport k3b (sid -->etch) problème apt-get build-dep + dpkg-buildpackage

2005-12-09 Par sujet Philippe Merlin

Bonjour,
Cela n'engage que moi mais j'ai l'impression que la nouvelle version du 
gcc-4.0  pour etch va être diffusé prochainement.
Alors K3B, digikam, kaffeine + . seront alors disponible, toujours dans 
mon rêve.
A+
Philou75


Le Vendredi 9 Décembre 2005 13:50, HEHO a écrit :
> Le 08.12.2005 12:40, HEHO exprima :
> > bonjour,
>
> bon bah, je vais tester xcdroast.
> à plus.
> hého

Re: backport k3b (sid -->etch) problème apt-g et build-dep + dpkg-buildpackage

2005-12-09 Par sujet HEHO

Le 08.12.2005 12:40, HEHO exprima :
> bonjour,

bon bah, je vais tester xcdroast.
à plus.
hého


-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

backport k3b (sid -->etch) problème apt-get build-dep + dpkg-buildpackage

2005-12-08 Par sujet HEHO

bonjour,
(je reprend ce message (une dernière fois) qui s'est éclaté en plusieurs
fils(??), aprés avoir annulé les articles du forum (mais pas de la
mailing-list désolé))

j'ai essayé de retro-porter k3b de sid dans mon système en etch(kernel
2.6.12, gcc 3.3.6).
comme dit  là:
http://marmottux.org/index.php/2005/11/26/459-installer-k3b-dans-debian-testing-parce-que-le-package-est-parti

j'ai donc rajouté :
deb-src http://ftp.fr.debian.org/debian sid main contrib non-free
à mon sources.list
puis
"apt-get update"
"apt-get source k3b"
et quand je lance
"apt-get build-dep k3b"
j'ai ça :
"Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
E: Les dépendances de compilation pour k3b ne peuvent pas être satisfaites."
pas d'autres messages.

dans le fichier k3b_0.12.8-1.dsc installé par apt-get source il y a :

Build-Depends: debhelper (>> 4.1.0), kdelibs4-dev (>= 3.2.1),
libqt3-compat-headers, libflac++-dev (>= 1.1.2-1), flac, dbus-qt-1-dev,
libhal-dev, libhal-storage-dev, libpopt-dev, libmpcdec-dev,
libresmgr-dev, libtag1-dev, libmusicbrainz4-dev

j'ai donc installé les librairies de dev nécessaires.
(toujours le meme message pour "apt-get build-dep k3b")

d'aprés ce que j'ai trouvé dans mes recherches en installant ces
librairies le "apt-get
build-dep" a été effectué "à la main"

donc ensuite je lance :
"dpkg-buildpackage -rfakeroot"

et là j'ai une erreur :
configure:3682: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.

config log fait 13 pages, et n'y connaissant pas grand chose je ne sais
pas trop quoi copier ici.

d'autre part mon système est à peu prés à jour et
apt-get upgrade -s, apt-get dist-upgrade -s donne :
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Les paquets suivants ont été conservés :
  cpp g++ gcc
0 mis à jour, 0 nouvellement installés, 0 à enlever et 3 non mis à jour.

gcc, g++, cpp --> version : 3.3.5-3

auriez-vous une piste?
merci
hého









-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: backport k3b (sid -->etch) problème apt-g et build-dep

2005-12-07 Par sujet HEHO

Le 07.12.2005 15:20, HEHO exprima :

>>
>> dois-je installer ces librairies ou c'est build-dep qui est censé s'en
>> charger? (par exemple kdelibs4-dev, libflac++-dev ne sont pas, entre
>> autres, installées)


re,
j'ai donc installé les librairies de dev nécessaires.
(toujours le meme message pour "apt-get build-dep k3b")

mais je me demandai si en installant ces librairies le "apt-get
build-dep" n'avait pas été effectué
et si je ne pouvais pas passer à l'étape suivante :
"dpkg-buildpackage -rfakeroot"

qu'en pensez-vous?

hého.




-- 
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

1 2 3 4 >

1 - 100 sur 313 matches

Mail list logo