Re: Question sur les bugs

2005-06-04 Par sujet claude

Christian Perrier wrote:

Quoting Alain Cabiran ([EMAIL PROTECTED]):


Bonjour,

une question certainement idiote : pourquoi, y'a-t-il de nombreux
très vieux bugs non fermés, concernant des versions de logiciels
tellement anciennes qu'ils ne semblent plus applicables (paquets plus
disponibles dans la version du bug rapporté) ?


Une des raisons essentielles est souvent la manque de ressources de la
part du mainteneur pour maintenir la base de bogues dans un état de
propreté correct.


OK... J'en déduis que c'est pour cela qu'apt-listbugs me ressort souvent 
de faux bugs - genre un problème de sécurité que justement la MAJ 
corrige ou qui ne concerne qu'une architecture/version (je suis en Sid 
et les pbs affectant l'installation sur woody ou Sarge me concernent 
assez peu ;)



La plupart apprécieront donc certainement de l'aide sur ce sujet et
c'est d'ailleurs un des domaines où les non DD peuvent le plus
facilement aider (avec la traduction...).


Aïe ! Je n'ai déjà malheureusement même plus le temps d'aider aux 
relectures des traductions, alors l'examen des vieux bogues et leur 
fermeture... :(



Une autre raison sont souvent les bogues corrigés dans testing et
unstable, mais pas dans woody. Ceux-ci doivent être marqués woody mais
pas fermés, en toute logique. Cela peut expliquer de très nombreux
bogues ouverts qui seront fermés dès que sarge sera publiée (ce coup
là, on y est...).


Comme je ne suis pas du tout programmeur, j'énonce peut-être une 
énormité, mais ne serait-il pas possible qu'apt-listbugs ne ressorte que 
les bugs pour l'architecture/version qu'on utilise ? (grosso modo, il 
suffirait d'un tag architecture : i386/mipsel/sparc etc. et d'un autre 
pour Woody, Sarge, Sid - ce dernier semblant déjà exister).


Cela pourrait permettre un certain gain en bande passante sur les 
serveurs et miroirs, je pense : actuellement, on télécharge les paquets 
puis apt-lisbugs annonce la couleur et on choisit ou non d'installer le 
paquet. Mais à ce moment-là, on l'a déjà téléchargé (sauf erreur 
grossière de ma part ;)


Ceci étant, je suis bien conscient que ce n'est certainement pas si 
simple que cela à réaliser :-D



Mais, en résumé, une aide aux mainteneurs pour faire ce genre de tri
peut être très appréciée. Fais gaffe, c'est pile comme ça qu'on se
retrouve co-mainteneur...:-)


Ah, si j'avais un peu de temps libre... :)

--
Amicalement,
Claude Thomassin


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



Re: Bilan Solutions Linux 2004

2004-02-10 Par sujet claude
Sven Luther a écrit :
[...]
Etant moi meme a la recherche d'un emploi en ce moment, je me
lancerai bien dans une aventure de ce style, mais pas tout seul.
Me too. D'ailleurs, je reviens d'un entretien où l'on me propose de
bosser en freelance pour de l'installation/réparation/maintenance en
réseaux (je suis technicien/admin réseau).
C'est une idée très intéressante. Je pensais que c'était le
créneau de sociétés comme Alcôve ou Idealx, mais apparemmement le
vide ne semble pas comblé puisqu'il y a une forte demande pour ça

Re: Experimental?

2003-09-22 Par sujet claude
Sven Luther a écrit :
[...]
Il te suffit de mettre experimental a la place de unstable dans le
changelog.
question con, au passage : c'est quoi exactement, experimental ? Je 
connaît stable/testing/unstable, mais experimental ?

Claude



Re: lancement d'un daemon lors d'un upgrade

2003-08-20 Par sujet claude
Benoit Friry a écrit :
Bonjour,
Lors de l'upgrade d'un paquet correspondant à un daemon[1], le script de
pré-installation l'arrête[2] et le script de post-installation le
relance[3] quel qu'est été l'état précédent.
Je trouve ce comportement erroné, dans la mesure où l'upgrade ne remet
pas le système dans l'état où il était avant, ni même dans l'état
correspondant à son initlevel (system V).
Oui, je suis d'accord avec toi... Ca m'est arrivé plusieurs fois, et si 
on upgrade beaucoup de paquets en même temps, c'est limite lourdingue :(

Claude