gratifiant > linux.debian.user.french

Thierry B (20/11/2005, 21h00)
Bonjour,

Appremment, amarok et k3b ont ete viré de testing, d'ou le problème
persistant que j'avais lors d'un dist-upgrade.

Même en mettant la source de planet moll, indiqué sur le site de k3b
pour testing, il veut pas l'installer à cause d'un pb de dependance...

Je voulais savoir ce que vous me conseilleriez?

Passer sous Sarge ?
Passer sous Unstable ?

Ou bien y'a t'il une autre solution à mon pb?

Moi je veux qque chose qui marche bien avec quand meême qques maj, de
temps en temps, pour que ce soit sympathique, d'où mon choix, de passer
d'unstable à testing...

Mais bon, amarok et k3b etaient quand même des paquets essentiels :-(.

J'attends vos conseils, et je vous remrcie :-)

A+
JusTiCe8 (20/11/2005, 21h30)
Bonsoir,

Thierry B a écrit :

> Bonjour,
> Appremment, amarok et k3b ont ete viré de testing, d'ou le problème
> persistant que j'avais lors d'un dist-upgrade.

voir les rapport de bugs, il y a un pb de dépendance en ce moment...
transition oblige.

> Même en mettant la source de planet moll, indiqué sur le site de k3b
> pour testing, il veut pas l'installer à cause d'un pb de dependance...
> Je voulais savoir ce que vous me conseilleriez?
> Passer sous Sarge ?
> Passer sous Unstable ?
> Ou bien y'a t'il une autre solution à mon pb?


attendre !
Je suis aussi en testing, j'utilise k3b et d'autres et j'attends que
cette transition soit terminée.
Philippe Merlin (20/11/2005, 21h30)
Bonjour,
De ce problème on en a déjà parler dans la liste, effectivement depuis la
migration de kde de 3.3 à 3.4.2 Amarok,digikam, k3b sont retirés de Etch, en
tout pour mon cas 45 logiciels.
C'est pour cela que je n'ais pas migrer en 3.4.2, j'attends avec impatience
que ces paquets réaparaissent, ils semblent être bloqués à cause dela
version de gcc de Etch, il parait aussi que cette situation évolue
favorablement, une affaire de patience de 1 à 10 jours, toujours si j'ai bien
compris.
A+
Philou75

Le Dimanche 20 Novembre 2005 19:50, Thierry B a écrit :
[..]
Thierry B (20/11/2005, 21h40)
Philippe Merlin a écrit :
[..]
> A+
> Philou75
> Le Dimanche 20 Novembre 2005 19:50, Thierry B a écrit :

Ok.
Merci :-)

A+
Thierry B (21/11/2005, 00h20)
Philippe Merlin a écrit :
[..]
> A+
> Philou75
> Le Dimanche 20 Novembre 2005 19:50, Thierry B a écrit :


J'avais aussi posté, mon problème autre part en plus que sur la liste
debian , et on m'a dit ceci:


Est-ce vrai que la testing est par deuction moins stable que la unstable?

Moi je pense que qd y'a des trucs bugués sur unstable, quand ca sort x
jours après sur testing, ces bugs sont corrigés lol...enfin j'espere
sinon aucun interet d'etre en testing...lol.

Merci :-)
A+
Leopold BAILLY (21/11/2005, 00h30)
Thierry B <debian> writes:

> Bonjour,
> Appremment, amarok et k3b ont ete viré de testing, d'ou le problème
> persistant que j'avais lors d'un dist-upgrade.
> Même en mettant la source de planet moll, indiqué sur le site de k3b
> pour testing, il veut pas l'installer à cause d'un pb de dependance...
> Je voulais savoir ce que vous me conseilleriez?


Rétro-porter le paquet de sid.

Je n'ai pas l'impression que c'est une habitude très répandue, pourtant c'est
souvent d'une simplicité enfantine.

Ça permet souvent de se sortir aisément de ces problèmes de dépendances et c'est
également AMHA la meilleure façon de mixer les différentes distributions
(stable/testing ou testing/unstable).

J'ai le même problème que toi à propos de digikam et j'ai pu sans souci compiler
le paquet de sid.

Les commandes magiques sont apt-get source, apt-get build-dep et
dpkg-buildpackage -rfakeroot.
Leopold BAILLY (21/11/2005, 00h50)
Thierry B <debian> writes:

> Philippe Merlin a écrit :


[...]

>>>Appremment, amarok et k3b ont ete viré de testing, d'ou le problème
>>>persistant que j'avais lors d'un dist-upgrade.


[...]

> J'avais aussi posté, mon problème autre part en plus que sur la liste
> debian , et on m'a dit ceci:
>
> Est-ce vrai que la testing est par deuction moins stable que la unstable?


Faut pas abuser, il ne s'agit en rien d'un problème de stabilité : certaines
mises à jour sont bloquées le temps de résoudre les problèmes, un point c'est
tout.

Testing n'évolue pas aussi vite de sid et c'est *normal* ; stable évolue encore
plus lentement et c'est *normal*.

Plus c'est stable, moins ça bouge et plus ça bouge, moins c'est stable. Sur
cette échelle, Debian donne le choix entre 3 compromis (sans compter
experimental, versatile et je ne sais quoi d'autre) et c'est déjà remarquable.
Thierry B (21/11/2005, 08h10)
Leopold BAILLY a écrit :
[..]
> le paquet de sid.
> Les commandes magiques sont apt-get source, apt-get build-dep et
> dpkg-buildpackage -rfakeroot.


Salut,

Euh, ca me semble pas si ssimple lol.

Tu peux me donner un exemple concret avec ces commandes, si tu as le
temps bien entendu?

Je te remercie bcp :-)

A+
Thierry B (21/11/2005, 08h10)
Leopold BAILLY a écrit :
[..]
> Plus c'est stable, moins ça bouge et plus ça bouge, moins c'est stable. Sur
> cette échelle, Debian donne le choix entre 3 compromis (sans compter
> experimental, versatile et je ne sais quoi d'autre) et c'est déjà remarquable.


Re,

Non, je me suis mal exprimé...
Je voulais savoir si un bug dans un paquet unstable, par exemple, que
l'on a en téléchargeant trop rapidement un paquet, se propagera
forcément sur une testing?

Car pour moi l'avantage d'une testing, c'etait d'avoir moins de bugs
dans les paquets du fait, que la maj se fera dans plus de temps, non?

Merci :-)
A+
Thierry B (21/11/2005, 13h40)
Leopold BAILLY a écrit :
[..]
> le paquet de sid.
> Les commandes magiques sont apt-get source, apt-get build-dep et
> dpkg-buildpackage -rfakeroot.


Ok.

Je crois avoir compris. Je vais t'expliquer ce que j'ai fait:

J'ai modifié mon fichier préférence comme ceci:
Tous les paquets de la cible unstable ont une priorité de 500
# le a=unstable est là pour dire à apt quelle archive utiliser
Package: *
Pin: release a=unstable
Pin-Priority: 500

# Les paquets de la cible testing reste avec un priorité supérieure, pour
# éviter que les paquets de unstable remplacent tous ceux de testing.
Package: *
Pin: release a=testing
Pin-Priority: 990

Ensuite, j'ai rajouté la source d'unstable dans mon source.list:
deb-src unstable main contrib non-free

j'ai ensuite fait:
apt-get source amarok qui est donc censé me telecharger les sources de
debian
apt-get build-dep amarok qui telecharge les paquets testing dependant
d'amarok (version unstable)
et enfin
dpkg-buildpackage -rfakeroot qui me construit mon paquet deb ou mes
paquets debs,

Est-ce que j'ai bien compris?

Appremment, la version d'unstable d'amarok bugue.
Ce n'est pas etonnant car ils disent ici
()

Et j'ai verifié, ca bugue à mort...

Mais ils disent de prendre pour résoudre le pb la version d'amarok
1.3.5-1 d'ici ().

J'ai téléchargé les trois fichiers, mais là, je ne sais pas du tout
comment procéder...

car quand je fais ca:
debian:/home/thierry# dpkg-buildpackage -rfakeroot
dpkg-parsechangelog: error: cannot open debian/changelog to find format:
Aucun fichier ou répertoire de ce type

Et effectivement, aucun de ces fichiers, n'ont le rep debian...:-(

Donc j'aimerais savoir si par hasard, tu c comment je pourrai installer
la version 1.3.5-1 facilement version debian?
Je voulais asussi te demander autre chose, quand j'ai fait apt-get
build-dep, il m'a télchargé plein de trucs....

Quand j'ai voulu desinstaller amarok d'unstable, j'ai viré tous les deb,
et même avec deborphan, il ne me retrouve pas tous les paquets qu'il m'a
installé en plus avec apt-get build-dep.

Comment je pourrais virer ces paquets là?

Merci
A+
Leopold BAILLY (22/11/2005, 00h50)
Thierry B <debian> writes:

> Leopold BAILLY a écrit :
>> Thierry B <debian> writes:


[...]

> Je voulais savoir si un bug dans un paquet unstable, par exemple, que
> l'on a en téléchargeant trop rapidement un paquet, se propagera
> forcément sur une testing?


Dans unstable, on a le tout venant. Je crois que la structure du paquet, le fait
qu'il compile, les dépendances, etc sont vérifiés, mais le fonctionnement même
du logiciel contenu n'est pas vérifié.

Au bout d'un certain temps, on regarde les rapports de bugs fait sur ce paquet ;
s'ils ne sont pas trop critiques, le paquet descend automatiquement en testing.

En conclusion, si un paquet de unstable est buggé, il ne descend pas en testing.

> Car pour moi l'avantage d'une testing, c'etait d'avoir moins de bugs
> dans les paquets du fait, que la maj se fera dans plus de temps, non?


C'est ça. Mais la fiabilité d'un paquet est directement liée à la quantité
d'utilisateurs qui vont découvrir et rapporter des bugs.

On appelle ici "bug" un bug découvert. Si personne ne teste le paquet, il
descendra automatiquement dans testing, buggé ou pas.
Leopold BAILLY (22/11/2005, 01h50)
Thierry B <debian> writes:

> Leopold BAILLY a écrit :
>> Thierry B <debian> writes:


[...]

>> Rétro-porter le paquet de sid.


[...]

[..]
> Package: *
> Pin: release a=testing
> Pin-Priority: 990


OK, mais si tu prends l'habitude de rétro-porter les paquets, tu n'auras plus
besoin de la cible binaire de unstable.

[..]
> 1.3.5-1 d'ici ().
> J'ai téléchargé les trois fichiers, mais là, je ne sais pas du tout
> comment procéder...


$ dpkg-source -x amarok_1.3.5-1.dsc

Ceci va te créer l'arborescence. Ensuite :

$ cd amarok-1.3.5
$ dpkg-buildpackage -rfakeroot

> Je voulais asussi te demander autre chose, quand j'ai fait apt-get
> build-dep, il m'a télchargé plein de trucs....
> Quand j'ai voulu desinstaller amarok d'unstable, j'ai viré tous les deb,
> et même avec deborphan, il ne me retrouve pas tous les paquets qu'il m'a
> installé en plus avec apt-get build-dep.
> Comment je pourrais virer ces paquets là?


À ma connaissance apt-get ne le permet pas.

J'ai profité d'un récent fil pour me mettre à aptitude qui est plus puissant de
ce côté là. Il distingue les paquets installés explicitement de ceux installés
implicitement.

Pour ça, il faut d'abord initialiser la base de données en se tapant tous les
paquets un à un. On commence par tout marquer "automatique" (M) (on peut le
faire sur une branche entière), puis on marque en "manuel" (m) les paquets de
plus haut niveau que l'on souhaite garder.

Les paquets installés par apt-get sont considérés comme "automatique".

Je vient d'ailleurs de le vérifier : aptitude puis g m'a permis de retirer les
paquets -dev et des librairies utilisés lors de récentes compilations.
Thierry B (22/11/2005, 11h21)
Leopold BAILLY a écrit :
> Thierry B <debian> writes:
> [...]
> [...]
> OK, mais si tu prends l'habitude de rétro-porter les paquets, tu n'auras plus
> besoin de la cible binaire de unstable.


Ha ok.
Doc on est pas obligé de rajouter la source d'unstable, si on l'utilise
dans les preferences, si j'ai bien compris.

Dis moi, pa curiosié, est-ce qu'il y aurait une solution si on veut
installer un binaire d'unstable (si par exemple y'a des pbs dessus en
testing), sans casser les dépendances comme tu m'as montré, mais en
installant directement le binaire pq ca prend du temps de compiler...lol.

Ta méthode à toi est pas mal, car apt-get build-dep à partir du source
unstable d'un paquet permet d'installer les paquets testing, qui
correspondent à la dépendance d'unstable, ce qui fait qu'en installant
que des paquets testing, (à part l'appli concerné unstable), on risque
pas de pb, donc j voulais savoir si on pouvait faire pareil pou
installer un binaire unstable au lieu d'une source unstable :-).

> $ dpkg-source -x amarok_1.3.5-1.dsc
> Ceci va te créer l'arborescence. Ensuite :
> $ cd amarok-1.3.5
> $ dpkg-buildpackage -rfakeroot


Ha ok, merci :-)

> À ma connaissance apt-get ne le permet pas.
> J'ai profité d'un récent fil pour me mettre à aptitude qui est plus puissant de
> ce côté là. Il distingue les paquets installés explicitement de ceux installés
> implicitement.
> Pour ça, il faut d'abord initialiser la base de données en se tapant tous les
> paquets un à un. On commence par tout marquer "automatique" (M) (on peut le
> faire sur une branche entière), puis on marque en "manuel" (m) les paquets de
> plus haut niveau que l'on souhaite garder.


Si j'ai bien compris,
Je vais sur chaque branche principale (j'ai tout ca comme branches:
"Paquets pouvant etre mise à jour", "Nouveau maquets", "paquets
installés", "paquets non installés", "paquets obsolètes ou crées
localement", "paquets virtuels" et "tache"), et pour chacune de ces
branches, je fais un marquage auto de paquet ? (je prefère demander
avant de faire une connerie lol)

> Les paquets installés par apt-get sont considérés comme "automatique".
> Je vient d'ailleurs de le vérifier : aptitude puis g m'a permis de retirer les
> paquets -dev et des librairies utilisés lors de récentes compilations.


Ha ok.
Donc si des paquets sont installés avec apt, même si on utilis aptitude,
il ne fera juste que marquer ces paquets en auto.

Merci bcp :-).
A+
Leopold BAILLY (23/11/2005, 00h10)
Thierry B <debian> writes:

> Leopold BAILLY a écrit :
>> Thierry B <debian> writes:
>>>Leopold BAILLY a écrit :
>>>>Thierry B <debian> writes:


> Dis moi, pa curiosié, est-ce qu'il y aurait une solution si on veut
> installer un binaire d'unstable (si par exemple y'a des pbs dessus en
> testing), sans casser les dépendances comme tu m'as montré, mais en
> installant directement le binaire pq ca prend du temps de compiler...lol.


Tu télécharge le .deb et tu tente un dpkg -i. Les chances que ça passe sont
minimes, mais c'est possible.

Tu peux y aller franco, soit ça s'intalle et c'est OK, soit dpkg t'envoie bouler
en raison d'une dépendance non satisfaite.

> Ta méthode à toi est pas mal, car apt-get build-dep à partir du source
> unstable d'un paquet permet d'installer les paquets testing, qui
> correspondent à la dépendance d'unstable, ce qui fait qu'en installant
> que des paquets testing, (à part l'appli concerné unstable), on risque
> pas de pb, donc j voulais savoir si on pouvait faire pareil pou
> installer un binaire unstable au lieu d'une source unstable :-).


L'intérêt de partir des sources est que les dépendances sont bien moins
fortes que sur le binaire. Je ne sais d'ailleurs pas pourquoi.

Je me demande même si c'est réllement justifié ( contrainte de l'éditeur de lien
? ) ou si c'est un effet de bord de l'outil de construction de paquet qui ne
sait pas faire mieux que "photographier" les librairies utilisées lors de la
compilation.

Y aurait-il un DD dans la salle, pour éclairer ma lanterne ?

> Si j'ai bien compris, Je vais sur chaque branche principale (j'ai tout ca
> comme branches: "Paquets pouvant etre mise à jour", "Nouveau maquets",
> "paquets installés", "paquets non installés", "paquets obsolètes ou crées
> localement", "paquets virtuels" et "tache"), et pour chacune de ces branches,
> je fais un marquage auto de paquet ? (je prefère demander avant de faire une
> connerie lol)


Oui, mais tu peux travailler sur des sous-branches, si tu hésites.

Au départ, c'est impressionnant car aptitude veux tout virer, puis la liste se
réduit au fur et à mesure des "m".

>> Les paquets installés par apt-get sont considérés comme "automatique".
>> Je vient d'ailleurs de le vérifier : aptitude puis g m'a permis de retirer
>> les paquets -dev et des librairies utilisés lors de récentes compilations.

> Ha ok. Donc si des paquets sont installés avec apt, même si on utilis
> aptitude, il ne fera juste que marquer ces paquets en auto.


Disons que si tu installes des paquets avec apt-get, ils risquent de disparaître
à la prochaine utilisation d'aptitude.
Thierry B (23/11/2005, 01h00)
Leopold BAILLY a écrit :
[..]
> réduit au fur et à mesure des "m".
> Disons que si tu installes des paquets avec apt-get, ils risquent de disparaître
> à la prochaine utilisation d'aptitude.


Re,

T'es sur qu'il y a un interet a tyous les mettre en auto au debut?

J m'explique.

J'ai lancé un apt-get update && apt-getupgrade, et donc il m'a dit la
liste de s paqets a mettre a jour.

Je n'ai pas lancé la maj.

Puis j'ai lancé, un aptitude update && a^titude upgrade, et là, il m'a
affiché, les mm paquets qu'avec apt, à mettre à jour, j'ai pas accepté
non plus, pour ne pas enregistrer d'actions dans aptitude, tant que je
suis pas sur qu'il soit bien configuré.

Donc vu qu'aptitude savait deja les bons paquets à mettre à jour, je
comprends pas pkoi il faut mettre tous les paquets en auto au depart lol ?
Pour qu'il soit en mesure de virer des le depart les paquets inutiles?
(cad non utilisés par des paquets marqués "m")

Merci
A+

Discussions similaires