Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Migration vers GCC5 laborieuse

2 views
Skip to first unread message

C. Mourad Jaber

unread,
Aug 12, 2015, 10:40:03 AM8/12/15
to
Bonjour,

Un petit point sur les grands travaux d'été debian...

Tout d'abord, le passage à plasma 5 qui ne s'est fait dans la douleur, avec beaucoup de
migration impromptue dans la testing de manière anarchique... et dont les effets de bord
ne sont pas encore terminés.

Ensuite un projet de grande ampleur, la migration vers gcc 5... Aujourd'hui, cela bloque
pas mal de chose et il ne me semble pas possible d'avoir une installation utilisable avec
tellement de paquetages "bas niveau" ne sont pas encore disponible...

Y'a-t-il une solution pour effectuer cette migration ou bien faut-il simplement attendre
que tous les mainteneurs de paquetage recompilent leurs applications ?

++

Mourad

Haricophile

unread,
Aug 12, 2015, 11:10:04 AM8/12/15
to
Le Wed, 12 Aug 2015 16:33:02 +0200,
"C. Mourad Jaber" <m...@nativobject.net> a écrit :
Perso j'étais arrivé à une situation indémerdable avec SID et j'ai
rétrogradé en testing avec succès : pinning 1001 pour testing et 100
pour SID + experimental mais je crois que je n'ai que Iceweasel dans ce
cas. Ensuite je suis repassé en 900 pour testing. J'ai même pu
réinstaller kde-full et Libreoffice.

Sylvain L. Sauvage

unread,
Aug 12, 2015, 11:20:02 AM8/12/15
to
Le mercredi 12 août 2015, 16:33:02 C. Mourad Jaber a écrit :
> Bonjour,

’jour,

> Un petit point sur les grands travaux d'été debian...
>
> Tout d'abord, le passage à plasma 5 qui ne s'est fait dans la
> douleur, avec beaucoup de migration impromptue dans la
> testing de manière anarchique... et dont les effets de bord
> ne sont pas encore terminés.

Plasma 5 est Ok en Sid (’fin, ça l’était avant GCC 5, fallait
mettre à jour au bon moment ;oP ).

> Ensuite un projet de grande ampleur, la migration vers gcc
> 5... Aujourd'hui, cela bloque pas mal de chose et il ne me
> semble pas possible d'avoir une installation utilisable avec
> tellement de paquetages "bas niveau" ne sont pas encore
> disponible...
>
> Y'a-t-il une solution pour effectuer cette migration ou bien
> faut-il simplement attendre que tous les mainteneurs de
> paquetage recompilent leurs applications ?

En fait, il semblerait qu’il n’y a pas seulement besoin de
recompiler (sinon je pense que ça se ferait un peu plus vite,
avec des [BO]NMU ([binary-only] non-maintainer upload) p.ex.),
il faut aussi adapter. Ça touche seulement le C++ (parce que
l’ABI C++ a changé pour C++11).

Il y a eu plusieurs messages précédant la migration :
https://lists.debian.org/debian-devel-announce/2015/07/msg00000.html
https://lists.debian.org/debian-devel-announce/2015/08/msg00000.html
https://lists.debian.org/debian-devel-announce/2015/08/msg00002.html

Donc, ouais, il faut attendre…

--
Sylvain Sauvage

C. Mourad Jaber

unread,
Aug 12, 2015, 11:40:02 AM8/12/15
to
Le 12/08/2015 17:09, Sylvain L. Sauvage a écrit :
> Le mercredi 12 août 2015, 16:33:02 C. Mourad Jaber a écrit :
>> Bonjour,
> ’jour,
>
>> Un petit point sur les grands travaux d'été debian...
>>
>> Tout d'abord, le passage à plasma 5 qui ne s'est fait dans la
>> douleur, avec beaucoup de migration impromptue dans la
>> testing de manière anarchique... et dont les effets de bord
>> ne sont pas encore terminés.
> Plasma 5 est Ok en Sid (’fin, ça l’était avant GCC 5, fallait
> mettre à jour au bon moment ;oP ).
Oui, j'ai eu le bon réflexe quand trop de morceau de plasma 5 sont tombés en testing (avec
la mise à jour de bluedevil et du network-manager en particulier)
>
>> Ensuite un projet de grande ampleur, la migration vers gcc
>> 5... Aujourd'hui, cela bloque pas mal de chose et il ne me
>> semble pas possible d'avoir une installation utilisable avec
>> tellement de paquetages "bas niveau" ne sont pas encore
>> disponible...
>>
>> Y'a-t-il une solution pour effectuer cette migration ou bien
>> faut-il simplement attendre que tous les mainteneurs de
>> paquetage recompilent leurs applications ?
> En fait, il semblerait qu’il n’y a pas seulement besoin de
> recompiler (sinon je pense que ça se ferait un peu plus vite,
> avec des [BO]NMU ([binary-only] non-maintainer upload) p.ex.),
> il faut aussi adapter. Ça touche seulement le C++ (parce que
> l’ABI C++ a changé pour C++11).
>
> Il y a eu plusieurs messages précédant la migration :
> https://lists.debian.org/debian-devel-announce/2015/07/msg00000.html
> https://lists.debian.org/debian-devel-announce/2015/08/msg00000.html
> https://lists.debian.org/debian-devel-announce/2015/08/msg00002.html
>
> Donc, ouais, il faut attendre…
C'est violent tout de même, une phase experimentale, même longue aurait peut-être été
préférable... Parce que là ça bloque tout SID pour longtemps !

3000 packages à vérifier/recompiler/tester manuellement, ça fait du boulot pour plusieurs
mois...

Mes 2 cents

Mourad

daniel huhardeaux

unread,
Aug 12, 2015, 1:30:04 PM8/12/15
to
Le 12/08/2015 17:38, C. Mourad Jaber a écrit :
> [...]
>> Donc, ouais, il faut attendre…
> C'est violent tout de même, une phase experimentale, même longue
> aurait peut-être été préférable... Parce que là ça bloque tout SID
> pour longtemps !
>
> [...]

L'essence même de SID est unstable ! On sait donc à quoi s'attendre ;-)

Rester en testing est la solution si l'on veut les dernières versions
sans les ennuis possibles d'unstable. Ou le pinning comme proposé
préalablement.

--
Daniel

Sylvain L. Sauvage

unread,
Aug 12, 2015, 3:30:04 PM8/12/15
to
Le mercredi 12 août 2015, 19:23:17 daniel huhardeaux a écrit :
>[…]
> Rester en testing est la solution si l'on veut les dernières
> versions sans les ennuis possibles d'unstable. Ou le pinning
> comme proposé préalablement.

Mais Sid a des mises à jour de sécurité plus rapides.
(Et Testing n’est pas beaucoup plus stable, les grosses
migrations n’y sont pas beaucoup plus rapides, juste un peu
moins risquées.)

--
Sylvain Sauvage

daniel huhardeaux

unread,
Aug 12, 2015, 6:10:03 PM8/12/15
to
Le 12/08/2015 21:22, Sylvain L. Sauvage a écrit :
> [...] (Et Testing n’est pas beaucoup plus stable, les grosses
> migrations n’y sont pas beaucoup plus rapides, juste un peu moins
> risquées.)

C'est uniquement pour ce dernier point que j'ai répondu, l'auteur
faisant le reproche de l'instabilité dans la durée et du risque de non
fonctionnement.

--
Daniel

MERLIN Philippe

unread,
Aug 13, 2015, 6:10:04 AM8/13/15
to

Le mercredi 12 août 2015, 17:09:53 Sylvain L. Sauvage a écrit :

 

> > Tout d'abord, le passage à plasma 5 qui ne s'est fait dans la

> > douleur, avec beaucoup de migration impromptue dans la

> > testing de manière anarchique... et dont les effets de bord

> > ne sont pas encore terminés.

>

> Plasma 5 est Ok en Sid (’fin, ça l’était avant GCC 5, fallait

> mettre à jour au bon moment ;oP ).

Sylvain pour moi qui suis en Sid AMD64 Kde, Plasma5 est non OK.

J'ai droit à des blocages continuels et c'est très désagréable un à plus de deux reboots par jour.

Tout d'abord la réactivité du lancement des applications c'est dégradé fortement. Le blocage se manifeste par l'impossibilité de lancer une nouvelle application ou de changer d'application au moyen de la barre d'activité du bas de l'écran.

Ce qui m'inquiète c'est que ce problème semble concerner plasmashell et a déjà été répertorié en mars de cette année sur les blogs kde une autre source d'inquiétude c'est si on crée un bug concernant ce problème il n'y a aucune réponse venant de l'équipe kde, ce qui est très désagréable.

Philippe Merlin

 

 

C. Mourad Jaber

unread,
Aug 13, 2015, 10:50:03 AM8/13/15
to
Le 13/08/2015 12:06, MERLIN Philippe a écrit :
>
> Le mercredi 12 août 2015, 17:09:53 Sylvain L. Sauvage a écrit :
>
> > > Tout d'abord, le passage à plasma 5 qui ne s'est fait dans la
>
> > > douleur, avec beaucoup de migration impromptue dans la
>
> > > testing de manière anarchique... et dont les effets de bord
>
> > > ne sont pas encore terminés.
>
> >
>
> > Plasma 5 est Ok en Sid (’fin, ça l’était avant GCC 5, fallait
>
> > mettre à jour au bon moment ;oP ).
>
> Sylvain pour moi qui suis en Sid AMD64 Kde,Plasma5 est non OK.
>
> J'ai droit à des blocages continuels et c'est très désagréable un à plus de deux reboots
> par jour.
>
> Tout d'abord la réactivité du lancement des applications c'est dégradé fortement. Le
> blocage se manifeste par l'impossibilité de lancer une nouvelle application ou de
> changer d'application au moyen de la barre d'activité du bas de l'écran.
>
> Ce qui m'inquiète c'est que ce problème semble concerner plasmashell et a déjà été
> répertorié en mars de cette année sur les blogs kde une autre source d'inquiétude c'est
> si on crée un bug concernant ce problème il n'y a aucune réponse venant de l'équipe kde,
> ce qui est très désagréable.
>
> Philippe Merlin
>
Je dois avouer que malgré quelques frayeur, globalement, j'ai un plasma 5 qui fonctionne
plutôt bien...

Par contre, la gestion des dépendence est à revoir.

Le truc qui pose problème est le systray qui n'est compatible qu'avec les applications
kde/plasma 5 et donc toutes les autres applications sont exclues...

Par contre, depuis l'importation de gcc5 en unstable, plus possible de faire la moindre
mise à jour sans dommages colatéraux important...

++

Mourad

Erwan David

unread,
Aug 13, 2015, 11:50:03 AM8/13/15
to
Le 13/08/2015 16:39, C. Mourad Jaber a écrit :
>
> Le truc qui pose problème est le systray qui n'est compatible qu'avec
> les applications kde/plasma 5 et donc toutes les autres applications
> sont exclues...
>
Ça pour moi c'est le point bloquant....

Sylvain L. Sauvage

unread,
Aug 13, 2015, 2:30:02 PM8/13/15
to
Le jeudi 13 août 2015, 16:39:06 C. Mourad Jaber a écrit :
>[…]
> > Sylvain pour moi qui suis en Sid AMD64 Kde,Plasma5 est non
> > OK.
> >[…]
> Je dois avouer que malgré quelques frayeur, globalement, j'ai
> un plasma 5 qui fonctionne plutôt bien...

Idem chez moi mais…

> Par contre, la gestion des dépendence est à revoir.

… c’était de ça dont je parlais principalement pour le « Ok ».

> Le truc qui pose problème est le systray qui n'est compatible
> qu'avec les applications kde/plasma 5 et donc toutes les
> autres applications sont exclues...

Moi, c’est l’absence d’interface dbus pour le presse-papier
qui me gêne (klipper 4 étant incompatible avec Plasma 5).

> Par contre, depuis l'importation de gcc5 en unstable, plus
> possible de faire la moindre mise à jour sans dommages
> colatéraux important...

Ouaip, faut passer par 'aptitude safe-upgrade' pour mettre à
jour parce que sinon, aptitude qui n’arrive pas à trouver (tout
seul) qu’il faut conserver les vieilles versions de gcc et
libstdc++ et non pas désinstaller tout le reste…

--
Sylvain Sauvage

Vincent Lefevre

unread,
Aug 14, 2015, 1:30:03 PM8/14/15
to
On 2015-08-12 19:23:17 +0200, daniel huhardeaux wrote:
> Le 12/08/2015 17:38, C. Mourad Jaber a écrit :
> >[...]
> >> Donc, ouais, il faut attendre…
> >C'est violent tout de même, une phase experimentale, même longue aurait
> >peut-être été préférable... Parce que là ça bloque tout SID pour longtemps
> >!
> >
> >[...]
>
> L'essence même de SID est unstable ! On sait donc à quoi s'attendre ;-)

"unstable", au sens où ça évolue. Là, c'est l'inverse: quasiment tout
est bloqué!

Dommage qu'il n'y ait pas un concept de branche pour les transitions,
de manière à ce que sid soit affecté de manière atomique par une
transition (pour le développement logiciel, on peut développer une
fonctionnalité dans une branche et faire un merge dans le tronc à la
fin).

> Rester en testing est la solution si l'on veut les dernières versions sans
> les ennuis possibles d'unstable. Ou le pinning comme proposé préalablement.

Non, testing n'a pas les dernières versions. Par exemple pour
iceweasel:

iceweasel:amd64 38.1.0esr-3 testing ftp.fr.debian.org
iceweasel:amd64 38.1.1esr-1 unstable ftp.fr.debian.org
iceweasel:amd64 38.2.0esr-1~deb8u1 stable security.debian.org

La 38.1.0esr-3 de testing a des trous de sécurité. Là on a tout de
même la chance de pouvoir passer en stable, qui n'est en fait plus
trop "stable" (au sens qui ne bouge pas) puisque la mise à jour de
sécurité l'a fait passer de 31.6.0esr-1 à 38.2.0esr-1~deb8u1, donc
un gros saut dans les versions.

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Vincent Lefevre

unread,
Aug 14, 2015, 1:30:03 PM8/14/15
to
Moi j'utilise:

// Tweak aptitude to not suggest removals as first option.
// Suggested on:
// https://lists.debian.org/debian-user/2014/07/msg00398.html
Aptitude::ProblemResolver::SolutionCost "removals";

Frédéric MASSOT

unread,
Aug 17, 2015, 9:50:02 AM8/17/15
to
Le 14/08/2015 16:20, Vincent Lefevre a écrit :
> On 2015-08-12 19:23:17 +0200, daniel huhardeaux wrote:
>> Le 12/08/2015 17:38, C. Mourad Jaber a écrit :
>>> [...]
>>>> Donc, ouais, il faut attendre…
>>> C'est violent tout de même, une phase experimentale, même longue aurait
>>> peut-être été préférable... Parce que là ça bloque tout SID pour longtemps
>>> !
>>>
>>> [...]
>>
>> L'essence même de SID est unstable ! On sait donc à quoi s'attendre ;-)
>
> "unstable", au sens où ça évolue. Là, c'est l'inverse: quasiment tout
> est bloqué!
>
> Dommage qu'il n'y ait pas un concept de branche pour les transitions,
> de manière à ce que sid soit affecté de manière atomique par une
> transition (pour le développement logiciel, on peut développer une
> fonctionnalité dans une branche et faire un merge dans le tronc à la
> fin).
>
>> Rester en testing est la solution si l'on veut les dernières versions sans
>> les ennuis possibles d'unstable. Ou le pinning comme proposé préalablement.
>
> Non, testing n'a pas les dernières versions. Par exemple pour
> iceweasel:
>
> iceweasel:amd64 38.1.0esr-3 testing ftp.fr.debian.org
> iceweasel:amd64 38.1.1esr-1 unstable ftp.fr.debian.org
> iceweasel:amd64 38.2.0esr-1~deb8u1 stable security.debian.org

Tu peux avoir un Iceweasel à jour avec testing, il suffit d'ajouter
cette ligne à ton fichier "sources.list" :

deb http://mozilla.debian.net/ jessie-backports iceweasel-release


$ apt-cache policy iceweasel
iceweasel:
Installé : 40.0-1~bpo80+1
Candidat : 40.0-1~bpo80+1
Table de version :
*** 40.0-1~bpo80+1 0
500 http://mozilla.debian.net/
jessie-backports/iceweasel-release i386 Packages
100 /var/lib/dpkg/status
38.2.0esr-1~stretch 0
500 ftp://ftp.fr.debian.org/debian/ stretch/main i386 Packages
38.2.0esr-1~deb8u1 0
500 http://security.debian.org/ jessie/updates/main i386 Packages
31.6.0esr-1 0
500 ftp://ftp.fr.debian.org/debian/ jessie/main i386 Packages


La page http://mozilla.debian.net propose un sélecteur de version pour
Iceweasel et affiche la ligne qui va bien pour le "sources.list".


--
==============================================
| FRÉDÉRIC MASSOT |
| http://www.juliana-multimedia.com |
| mailto:fred...@juliana-multimedia.com |
| +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 |
===========================Debian=GNU/Linux===

Vincent Lefevre

unread,
Aug 18, 2015, 6:20:02 AM8/18/15
to
On 2015-08-17 15:47:01 +0200, Frédéric MASSOT wrote:
> Le 14/08/2015 16:20, Vincent Lefevre a écrit :
> > Non, testing n'a pas les dernières versions. Par exemple pour
> > iceweasel:
> >
> > iceweasel:amd64 38.1.0esr-3 testing ftp.fr.debian.org
> > iceweasel:amd64 38.1.1esr-1 unstable ftp.fr.debian.org
> > iceweasel:amd64 38.2.0esr-1~deb8u1 stable security.debian.org
>
> Tu peux avoir un Iceweasel à jour avec testing, il suffit d'ajouter
> cette ligne à ton fichier "sources.list" :
>
> deb http://mozilla.debian.net/ jessie-backports iceweasel-release

Sauf que testing/unstable n'est pas jessie, donc il n'y a aucune
raison que ça marche (sauf éventuellement de manière temporaire,
car testing n'a pas encore assez évolué). En gros, c'est OK avant
la première transition affectant iceweasel, mais une fois que la
première transition a eu lieu, ça va bloquer.

> La page http://mozilla.debian.net propose un sélecteur de version pour
> Iceweasel et affiche la ligne qui va bien pour le "sources.list".

ce qui ne résout pas le problème avec les transitions, car on n'a
le choix qu'entre un iceweasel pour jessie et un iceweasel pour
unstable. Si la transition N a déjà été faite et qu'une nouvelle
transition N+1 est en cours, les mises à jours de sécurité vont
avoir des paquets qui s'appliquent à jessie et à la transition N+1,
mais pas à la transition N.

Pour info, dans le sélecteur, c'est

deb http://http.debian.net/debian experimental main

et

apt-get install -t experimental iceweasel

pour testing et unstable (pas de différence).
0 new messages