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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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
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...
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
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
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.
[...] (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
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.
[...] (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
C. Mourad Jaber
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
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...
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
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....
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...
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...
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...
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...
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...
On 2015-08-13 20:26:35 +0200, Sylvain L. Sauvage wrote:
Le jeudi 13 août 2015, 16:39:06 C. Mourad Jaber a écrit : > 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…
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";
On 2015-08-13 20:26:35 +0200, Sylvain L. Sauvage wrote:
Le jeudi 13 août 2015, 16:39:06 C. Mourad Jaber a écrit :
> 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…
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";
On 2015-08-13 20:26:35 +0200, Sylvain L. Sauvage wrote:
Le jeudi 13 août 2015, 16:39:06 C. Mourad Jaber a écrit : > 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…
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";
