Le gel de Debian 8, nom de code Jessie, la future version stable donc, a eu lieu comme prévu le 5 novembre 2014 à 23h59.
NdM : pour mémoire, Debian gère une version ancienne dite oldstable encore mise à jour (Debian 6 Squeeze pour l'instant), une version courante dite stable (Debian 7 Wheezy), une version avancée/préparatoire dite testing (Debian 8 Jessie) et une version en évolution constante dite unstable (nom fixe, Debian Sid). Tous les noms de version sont tirés des noms de personnage des films d'animation Toy Story (à venir Debian 9 Stretch et Debian 10 Buster).
Les changements possibles ne sont plus que des corrections de bogues critiques et importants dans des logiciels qui ne font pas partie du noyau. À 18h (UTC) le jour de gel, 310 bugs critiques pour la sortie de Jessie étaient recensés. Des paquets non indispensables contenant des bugs critiques pourront être supprimés.
Comme de coutume, aucune date de sortie n'est prévue (mais la politique de gel prévoit des étapes les 5 décembre 2014, janvier et février 2015).
D'après le site listant les paquets Debian, les versions suivantes devraient être présentes (liste évidemment non exhaustive) :
- noyaux Linux 3.16.3 / Kfreebsd 10.1 ;
- Xen 4.4 / QEMU-KVM 2.1 ;
- Apache 2.4.10 / Nginx 1.6.2 ;
- MySQL Server 5.5.39 / Mariadb 10.0.14 /PostgreSQL 9.4 ;
- Squid 3.4.8 ;
- Exim 4.84 / Postfix 2.11.2 ;
- Dovecot 2.2.13 / Cyrus 2.4.17 ;
- Gnome 3.14 / KDE 4.14.2 / Xfce 4.10.1.
Aller plus loin
- Paquets Debian (539 clics)
- Debian-devel-announce: "Bits from the release team: Jessie Freeze" (170 clics)
- Debian: Freeze Policy for Jessie (149 clics)
- Debian-devel-announce: "Release Team Sprint Results" (102 clics)
# Kernel 3.16
Posté par Adrien.D . Évalué à 5.
Le kernel choisi est le 3.16 mais d'après kernel.org, il ne semble pas être "LTS".
Ils ne vont pas faire la même bêtise que Ubuntu ?
[^] # Re: Kernel 3.16
Posté par Dazul . Évalué à 8.
Selon ce mail qui date depuis un moment déjà, ils vont mettre la version 3.16 dans Jessie.
https://lists.debian.org/debian-kernel/2014/07/msg00361.html
Sachant que Ben Hutchings fait partie de l'équipe de Kernel.org, je pense qu'il sera en mesure de suivre la version 3.16 pour Debian sans trop de soucis.
[^] # Re: Kernel 3.16
Posté par Cyril Brulebois (site web personnel) . Évalué à 7.
Pour plus d'informations sur la maintenance de 3.16, notamment pour Ubuntu et Debian : https://lists.debian.org/debian-kernel/2014/10/msg00543.html
Debian Consultant @ DEBAMAX
[^] # Re: Kernel 3.16
Posté par Malizor . Évalué à 10.
En quoi le fait que des devs Ubuntu soient payés pour maintenir des noyaux upstream est une bétise ?
Faudrait savoir, on est content qu'ils contribuent ou pas ?
[^] # Re: Kernel 3.16
Posté par claudex . Évalué à 7.
Non, on n'est pas content. Après, on attend qu'ils fassent quelque chose pour savoir de quoi on n'est pas content.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Openjdk 8 absent
Posté par caranille . Évalué à 8. Dernière modification le 11 novembre 2014 à 02:01.
Moi qui suis passionné de Debian je suis néanmoins déçu que Openjdk 8 ne soit pas dans les dépôts alors que cela fait plus de 3 mois que java 8 est sorti.
Après on peut installer java manuellement mais bon je préfère utiliser les dépôts officiel. Bon ben plus que à ajouter le depot testing pour la future stable.
Dommage car Java 8 est une grande réussite par rapport au 7 et pour les entreprise qui veulent l'utiliser elle devront l'installer manuellement.
Ha je suis bien dégoûté honnêtement moi qui me faisais une joie de faire du dev java dessus je vais devoir bricoler. Ou utiliser ubuntu 14.10 qui incorporent openjdk 7 et 8
[^] # Re: Openjdk 8 absent
Posté par Dazul . Évalué à 3. Dernière modification le 11 novembre 2014 à 02:47.
Tu peux toujours l'importer depuis les dépots Sid.
[^] # Re: Openjdk 8 absent
Posté par Adrien . Évalué à 4.
Peut-être que les packageurs ont prévus de le mettre dans backport plus tard ?
[^] # Re: Openjdk 8 absent
Posté par Emmanuel Bourg . Évalué à 1.
Je confirme que c'est bien ce qui est prévu. OpenJDK 8 et OpenJFX 8 seront disponibles dans les backports.
[^] # Re: Openjdk 8 absent
Posté par Damien Raude-Morvan (site web personnel) . Évalué à 10. Dernière modification le 11 novembre 2014 à 11:07.
[Je prends ma casquette de membre de l'équipe Debian Java + OpenJDK]
Je comprends tout à fait ta déception, j'aurais également apprécié avoir la toute dernières version d'openjdk-8 comme version par défaut dans Jessie. Sauf que :
- l'équipe est vraiment très réduite : 1 à 2 personnes (typiquement cela fait plusieurs mois que je n'ai pas eu le temps de faire grand chose)
- en conséquence, il est clairement difficile de maintenir en même temps les deux versions dans la prochaine Jessie
- il restait trop de problème de compatibilité
Il est très fortement probable que openjdk-8 soit disponible dans les backports juste après la sortie de Jessie (maintenu par l'équipe Debian OpenJDK). Mais du coup, avec une garantie de qualité/sécurité plus faible qu'openjdk-7.
[^] # Re: Openjdk 8 absent
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
Wow on croise du beau monde sur linuxfr!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Openjdk 8 absent
Posté par barmic . Évalué à 10. Dernière modification le 12 novembre 2014 à 15:19.
Et t'en fait parti !
C'est l'un des gros avantages de ce site : à coté des poillus qui trollent, il y a des gens qui savent, qui sont impliqués et qui font les choses !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Sylvain Blandel . Évalué à 6.
En février 2014, Debian a adopté systemd comme système d'initialisation par défaut sur les architectures basées sur le noyau Linux. Cette décision fut prise après de trèèèèès longs débats.
9 mois plus tard, des discussions portent sur le support simultané de plusieurs systèmes d'init. En effet, une Résolution Générale est actuellement votée par les contributeurs du projet Debian, le vote se clôture dans une semaine (le 19 novembre 2014).
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par rogo . Évalué à 5.
Pour résumer, cette résolution veut interdire la dépendance unique à systemd en dehors des cas de force majeures (interface graphique sur systemd, etc) : tout paquet Debian devrait accepter plusieurs systèmes de démarrage.
Plusieurs amendements ont été ajoutés, chacun étant une possibilité de vote :
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 11 novembre 2014 à 10:51.
Moi qui croyais que c'était une liberté (discours politicien "freedom" partout dans la proposition initiale), mais finalement non, l'idée est d'imposer aux autres de faire du travail en plus.
J'espère que cette proposition va dégager avec un bon coup de pied aux fesses (moi, je veux que tous les paquets acceptés compilent sur toutes les architectures de Debian avant d'être validés, ce serait obligatoire et non conseillé, ça serait rigolo comme liberté).
Ca fait plaisir de voir les amendements (libre à tout le monde de bosser pour proposer la compatibilité, mais sans alourdir inutilement la charge de travail de ceux qui n'ont rien demandé!).
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par rewind (Mastodon) . Évalué à 8.
C'est le cas. Si les paquets ne compilent pas sur toutes les architectures, il y a des bugs qui sont ouverts pour le paquet sous le joli acronyme FTBFS (Fail To Build From Source) et le mainteneur du paquet doit les corriger (avec l'aide des responsables d'architecture). Debian met à disposition tout un ensemble de machine de toutes les architectures pour faire les tests. Donc, plutôt que de parler pour ne rien dire (ta spécialité), renseigne-toi avant de débiter une autre connerie.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Zenitram (site web personnel) . Évalué à -5.
il me semble, sans être sûr toutefois, qu'il y a des packages qui ne sont pas dispos sur certaines architectures et c'est quand même en release. Oui, je n'en suis pas sûr (il semble qu'il y ai 300 paquets chez Ubuntu qui ne compilent pas sur ARM, pas trouvé vite fait pour Debian)..
Bon, si tu refuses ce cas la (c'était un cas d'école, pour montrer le problème du principe "c'est évident, pour la liberté" en lui-même), je propose de refuser les packages qui ne compilent pas avec autre chose que GCC, c'est vrai quoi la liberté du compilateur c'est quand même important, plus important que de se passer de systemd!
Et la, je suis sûr que 6% des packages ne passent pas.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
Stats chez Debian : https://buildd.debian.org/stats/ (les deux images ci-dessous sont disponibles en meilleure résolution en cliquant dessus)
À comparer avec le Debian Popularity Contest :
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Spyhawk . Évalué à 3. Dernière modification le 11 novembre 2014 à 14:24.
Quand je vois que 98.6% des installations Debian tournent sur arch i386 ou x86_64 (99.3% si on ajoute ARM) selon le pop contest, je me dis que le travail requis pour maintenir le reste est un sacré gâchis de ressources inutile.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Zenitram (site web personnel) . Évalué à 8. Dernière modification le 11 novembre 2014 à 14:44.
Note : c'est en effet le choix fait par quasi toutes les autres distros, genre les gens qui pensent "thunes" comme RH (x86_64 ppc ppc64 s390x quand même) ou SuSE (x86 ppc64le s390x), donc certes, même avec d'autres métriques ce n'est pas forcément viable. après, si il y a des gens qui s'y collent… Le tout est comme mon premier message sur l'init, ça doit rester optionel, pour ceux qui veulent s'y coller et pas les autres.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Spyhawk . Évalué à 1.
C'est vrai, d'ailleurs on a déjà du faire la remarque (que j'avais totalement oubliée). Question sérieuse: si un bug n'est pas détecté par les architectures les plus importantes, peut-on considérer qu'ils ne sont pas important? Au final, ça permet d'améliorer la "beauté" du code, mais c'est peut être inutile dans la pratique?
Par contre, j'ai de gros doute quand au gros budget amené par des petites architectures.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Zenitram (site web personnel) . Évalué à 7.
Oui (potential de bug dormant, qui t'explosera à la figure violement un jour sans prévenir)
C'est un exemple pour montrer que la métrique choisie n'est pas forcément pertinente.
Pour info, perso à un moment j'avais bien 1% d'utilisateurs Linux (tout confondu) mais 25% de mon C.A. sous Linux. Sans compter que les gens sous Linux parlent plus aux autres. ca arrive d'être rentable. Je crois que chez les Indie bundle ça dépote aussi pas mal le petit pourcent d'utilisateurs Linux.
Bref, juste un exemple, pas une promesse que c'est le cas ici.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Spyhawk . Évalué à 4.
Merci.
Oui, on est d'accord la dessus. J'arrive à imaginer l'intérêt (et les sous qui vont avec) pour une archi un peu "exotique" pour des super-calculateurs, mais sur un nombre de paquets restreint, pas Debian et ses 50'000 paquets.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Yves (site web personnel) . Évalué à 3.
Ça va changer : la part de marché des architectures ARM est en forte croissance aussi bien chez les particulier pour l'auto-hébergement que chez les professionnels, qui voient dans ces architectures la possibilité de proposer des serveurs à faible consommation.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par gpe . Évalué à 1.
Faut voir car Intel pénètre le marché Android, on voit de plus en plus de tablettes Android en Intel …
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par cluxter . Évalué à 3.
Le smartphone 4G Neo900 (architecture ARM) embarquera Debian comme OS par défaut :
http://neo900.org/
Ce n'est possible que parce que Debian existe déjà pour les architectures ARM. Si l'on veut démocratiser Debian sur d'autres machines que les architectures x86 et x86_64, il faut d'abord que l'OS soit en mesure de tourner sur ces autres architectures. Je me vois mal concevoir un smartphone en disant "il va tourner sous Debian" et ne m'intéresser au portage de l'OS qu'après avoir conçu mon smartphone..! Donc le temps que l'OS soit adopté sur d'autres architectures, il faut attendre un peu.
Donc du gâchis, ça dépend comment on voit les choses. Ceux qui utilisent Debian sur les autres architectures doivent être très heureux de pouvoir le faire, et c'est peut être le seul OS grand public avec autant de paquets qui tourne sur autant d'architectures différentes, ce qui en fait peut être le seul OS réellement utilisable sur des architectures peu utilisées, ce qui a une grande valeur pour ceux qui en ont besoin.
Et puis ce n'est pas forcément le nombre de machines qui compte, l'importance des tâches accomplies par 10 machines peut être supérieure à celle réalisée par 10.000 machines. Exemple : je pense que 10 serveurs Wikipedia sont bien plus utiles que 10.000 serveurs YouTube pour regarder des vidéos de lolcats… Si pour une raison quelconque les serveurs de Wikipedia doivent tourner sous ARM (exemple : pour consommer moins d'énergie ==> développement durable ==> saybon, mangez-en), alors il faut que Debian soit déjà prévu pour cela avant de pouvoir le concrétiser.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Spyhawk . Évalué à 4.
Puisque que le fond de mon message plus haut n'est toujours pas bien passé, je le reformule ici:
Je ne nie pas l'intérêt d'une architecture qui monte comme ARM (d'où le second chiffre de 99.3% donné plus haut*), mais de la pertinence des efforts requis pour supporter un très grand nombre de paquets vis à vis du nombre d'utilisateurs potentiels au final.
En reprenant tes termes, je n'arrive pas à imaginer Wikipedia avoir besoin des 40 ou 50'000 paquets Debian pour les faire tourner sous Hurd, quand en pratique il n'y a que 21 types dans leur garage qui s'amusent avec ce noyau (et ceci, probablement pour regarder des lolcats).
*D'ailleurs avec ARM, la proportion des autres architectures va plutôt diminuer encore plus plutôt que l'inverse.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par cluxter . Évalué à 8.
J'ai bien compris ce que tu voulais dire, c'est peut être moi qui n'ai pas réussi à exprimer mon idée.
Même si c'est effectivement beaucoup d'efforts pour un nombre restreint d'utilisateurs, je pense que ce sont précisément ces utilisateurs qui changent le monde en faisant des trucs a priori inutiles, farfelus, mais qui façonnent peu à peu nos connaissances et nous donnent envie de créer chaque jour de nouvelles choses, utiles cette fois.
Quel intérêt de porter Linux sur une TI-89 ? On peut franchement se le demander. Sauf que j'ai eu énormément de plaisir à coder en assembleur sur ma TI-83 puis ma TI-89. Et ce que j'ai fait n'a servi à rien concrètement. Mais j'ai appris énormément de choses et la valeur que j'en tire aujourd'hui en valait sacrément la peine. Je pense aux boulots que ça m'a permis d'avoir, mais bien au-delà de ça de tout ce que ça m'a apporté comme connaissances et épanouissement personnel. Pour moi c'est ça le hacking.
Porter Debian sur autant d'architectures différentes nécessite une montagne de boulot incroyable, mais si on calcul le ratio Efforts requis / Nombre d'utilisateurs, alors autant laisser Microsoft faire son boulot et se contenter de ce qu'ils nous fournissent, plutôt que de chercher à économiser 5 cycles processeur sur une interruption appelée 3 fois par jour… Le libre c'est avant tout s'amuser à développer des systèmes pour la beauté de la chose. Si on peut rendre ça rentable, alors c'est carrément mieux, on est d'accord. Mais ce n'est pas ce qui a motivé le développement de Linux ou de Debian, et c'est pour ça que ce sont de si bons systèmes. Si ça amuse des mecs dans leur garage de maintenir des paquets qui ne servent à personne (même pas à eux), et bien le fait qu'ils prennent leur pied à le faire est déjà suffisant selon moi.
C'est sûr que j'aimerais qu'ils passent plus de temps à porter Compiz sous Debian Wheezy plutôt que de faire tourner des logiciels de radioamateur pour des PowerPC, mais les besoins et les motivations de chacun sont différents. Je suis sûr que les geeks barbus qui ne jurent que par la ligne de commandes se demandent bien pourquoi j'ai besoin de Compiz. Et pourtant…
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par ZeroHeure (site web personnel) . Évalué à 5.
Tu oublies NetBSD qui peut être utilisé sur plus de cinquante architectures différentes—cf en bas de la page http://www.netbsd.org/about/portability.html
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par cluxter . Évalué à 1.
Ah oui quand même x-)
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Zenitram (site web personnel) . Évalué à -9.
Merci, comme quoi mes connaissances ne m'ont pas fait défaut, même si je ne trouvais plus les stats.
J'imagine que rewind va s'excuser d'avoir sorti une énorme connerie, et dire que j'avais en fait raison et qu'il fera attention la prochaine fois que je dis quelque chose, et se dire à lui-même "Donc, plutôt que de parler pour ne rien dire (ta spécialité), renseigne-toi avant de débiter une autre connerie."
bizarrement, j'imagine qu'il va "oublier" de s'excuser et "oublier" de s'attaquer lui-même :).
J'adore quand les gens m'attaquent en disant que j'ai tort et que je devrai la fermer avec une telle confiance en ce qu'ils racontent, et quand la réalité leur revient dans la gueule!
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Anonyme . Évalué à 7.
Sauf que tu as dit une connerie pour faire une analogie : « il faudrait voter que tous les paquets compilent obligatoirement sur toutes les architectures », ce à quoi il a répondu : « quand ce n’est pas le cas, le mainteneur se voit assigner un bug report qu’il va s’efforcer de corriger ».
En réalité, on voit qu’il n’y a que très peu de paquets (en proportion en tout cas) qui ne sont pas disponible sur tout les architecture. Si on regarde dans le détail, je suis sûr que c’est les même paquets qui ne sont disponible que sur i386 et adm64. Autre exemple, je suppose que les paquets
linux-image-genericne sont pas disponible sur debian-kfreebsd.[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par flan (site web personnel) . Évalué à 1.
Si tu veux que ton logiciel soit accepté dans Debian, tu as de toute façon un certain nombre de contraintes à accepter. Libre à toi de les accepter ou non. Et de la même façon, libre à eux d'accepter (ou non) de faire le travail en question à ta place.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Adrien . Évalué à 10.
yep, c'est d'ailleurs assez triste de voir que les trolls sur systemd ont réussit à faire : Dans Debian, ça a aboutit à des guerres sans fin, plusieurs contributeurs historiques sont partis suite à ça… et au final un gros gâchit de temps pour tout le monde.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Barnabé . Évalué à -1.
Il s'agit bien de liberté, de la liberté des utilisateurs de choisir le système d'init de leur choix.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Zenitram (site web personnel) . Évalué à -10.
Merci pour voter pour ma liberté de te tuer (l'impact d'une liberté sur les autres n'ayant pas l'air de te déranger).
La liberté des uns s'arrête ou commence celle des autres, c'est assez souvent oublié dans ceux qui parlent de liberté à n'importe quelle sauce.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par Anonyme . Évalué à 2.
Le fait que tu sois obligé de modifier les propos de ton adversaire prouve que tu as tort.
On n’est pas en train de parler d’un État, du pouvoir qu’à le peuple ou des droits et devoirs qu’il ne peut outrepasser, on parle de Debian.
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par rewind (Mastodon) . Évalué à 2.
On en parle pour la GPL ? ;)
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par claudex . Évalué à 2.
Leurs patch sont donc attendus pour ces systèmes d'init. Pour rappel, il n'est pas interdit, déconseillé ou mal vu de gérer les autres systemd d'init.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Une Résolution Générale sur l'acceptation de plusieurs systèmes d'init.
Posté par anaseto (site web personnel) . Évalué à 3.
Il ne manquait plus que ça, plusieurs systemd ! :)
# C'est dommage
Posté par mickabouille . Évalué à -10.
C'est dommage, ce gel récurrent. Si encore sid n'était pas gelée en même temps. Il n'y a aucune raison de geler sid une fois que les paquets ne passent plus automatiquement dans testing !
En plus, je ne suis pas persuadé que ce freeze soit un gain pour Debian en général. Qui utilise stable ?
[^] # Re: C'est dommage
Posté par Morrock (site web personnel) . Évalué à 10.
Je ne peux pas m'exprimer au nom de la majorité, mais pour mon cas personnel, j'utilise stable pour une majorité de mes serveurs de production.
En desktop ou sur des serveurs de développement et certains serveurs non-critiques (utilisés à titre personnel ou associatif), j'utilise testing. Mais pour les serveurs que j'utilise à titre professionnel, ce sera toujours stable, éventuellement avec les backports activés si j'ai besoin d'une fonctionnalité particulière. Ca me permet d'avoir moins de travail de test en cas de déploiement de mises à jour, et surtout je peux laisser la main en cas d'urgence à quelqu'un qui n'a pas la même maîtrise sans craindre un plantage général des services.
Le Graal, je sais pas où il est mais il va y rester un moment, c'est moi qui vous l'dis !
[^] # Re: C'est dommage
Posté par rogo . Évalué à 2. Dernière modification le 11 novembre 2014 à 10:23.
Je ne connais pas de serveur qui soit en Debian testing ou unstable. J'ai vu des serveurs qui fonctionnaient sans évolution depuis des décennies, même si en général leur durée de vie est plus courte. Pour ces engins, il faut des systèmes d'exploitation stables.
Aucune raison, vraiment ? J'en vois plusieurs. Imagine que tu maintiennes le paquet Foobar. Ta version 1.0 est dans testing, mais comme il n'y a pas eu de gel, tu sors une 1.1 en unstable. Sauf qu'on découvre un bug critique en 1.0. Comment s'en sortir en gardant un historique linéaire ?
[^] # Re: C'est dommage
Posté par Spyhawk . Évalué à 5.
Qu'est ce qui empêche de maintenir les deux en parallèle, patcher Foobar 1.0 puis passer à Foobar 1.1 après le dégel? C'est ce que font bien d'autres distributions "stables" par ailleurs.
Garder un historique "linéaire" à tout prix un un peu idiot, surtout à l'époque du développement facilité par des VCS comme git.
[^] # Re: C'est dommage
Posté par Thuban (site web personnel) . Évalué à 7.
Moi j'utilise stable, et pas seulement pour le serveur.
Pourquoi?
Parce que quand on bosse, on a besoin d'un système fiable. On ne veut pas avoir à bricoler pour préparer les présentations du lendemain parce que tel dépendance est tout juste mise à jour et qu'il faut consulter les nouvelles du site principal pour entrer une commande permettant de tout résoudre (hello archlinux…). Parce que tu ne peut pas te permettre un bug après 3h de boulo non sauvegardés…
Et franchement, mis à part pour faire mumuse, ou pour une fonction supplémentaire révolutionnaire, avoir un logiciel plus à jour ne sert absolument à rien. Ça n'empêche pas debian stable d'inclure les mises à jour de sécurité.
[^] # Re: C'est dommage
Posté par xcomcmdr . Évalué à 4. Dernière modification le 11 novembre 2014 à 11:18.
Bah t'avais qu'à lancer la mise à jour après que le jour fatidique soit passé… Bref, y'a pas d'urgence au jour près pour les mises à jours, par contre pour ta présentation j'ai un doute qu'elle soit reportée parce que tu as lancé un pacman -Syu.
C'est fou comme c'est toujours la faute à la distro…
Bah ça sert au minimum d'être sûr que le bug qu'on vient de rencontrer n'est pas dû au fait que c'est une ancienne version.
Ça évite d'activer les backports, ou de rechercher un dépôt tierce…
Et ça évite de se taper une mise à niveau qui dure plusieurs heures (alors qu'une mise à jour de quelques minutes par semaine c'est moins bloquant) foire une fois sur deux à cause d'un PPA qu'on a oublié (hello Ubuntu).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est dommage
Posté par Spyhawk . Évalué à 8.
Ca dépend. Si tu attends de ta distro une stabilité sans faille, et qu'elle vise la stabilité à tout prix comme objectif, une mise à jour qui foire c'est entièrement sa faute. Si tu utilises une distro qui place la responsabilité de l'utilisateur comme pilier de la distribution, alors l'utilisateur est responsable quoiqu'il arrive.
Tout ça pour dire qu'on ne peut pas aborder Arch Linux avec la même attitude qu'une Debian stable, tant chacune vise un public différent.
[^] # Re: C'est dommage
Posté par Maderios . Évalué à 4.
Je bosse avec Sid. Pour éviter les éventuels ennuis de stabilité, il suffit de mettre à jour de manière "raisonnée". Quant à "faire mumuse", j'ai ramé dans le passé avec stable parce que des programmes n'étaient pas suffisamment aboutis. Passer à Sid a résolu pas mal de problèmes. Tout ceci ne concerne évidemment pas les serveurs.
Poster une information ne signifie pas nécessairement adhésion
[^] # Re: C'est dommage
Posté par woprandi . Évalué à -2.
Ça doit être génial de bosser encore avec libreoffice 3.5
[^] # Re: C'est dommage
Posté par ZeroHeure (site web personnel) . Évalué à 7.
C'est vrai tu as raison, avant on ne savait pas travailler, heureusement que LibO 4.0 nous a appris à le faire :-)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: C'est dommage
Posté par woprandi . Évalué à -1.
Je savais qu'une réponse se ce style allait arriver.
Si tu fais des trucs basiques tu ne verra peut être pas trop de différence mais sinon tu remarquera la différence de productivité
[^] # Re: C'est dommage
Posté par cluxter . Évalué à 0.
C'est dommage que tu ne saches pas ce que sont les rétroportages (backports en anglais).
Cf. mon commentaire plus bas pour plus d'explications si ça t'intéresse.
[^] # Re: C'est dommage
Posté par walken . Évalué à 4.
Complètement stupide ! En fait, beaucoup de mises à jours sont utiles si on élimine les mises à jours de sécurité. J'ai un exemple tout frais en tête, mon logiciel de programmation de radio, sous Stable, impossible d'utiliser mon radio, mais sous Testing la prise en charge est immédiate et automatique. Honnêtement je ne vois pas en quoi ici il s’agit de faire mumuse. Pour mon utilisation personnel si je suis en testing, c'est surtout pour la prise en charge de plus de matériel, et pour des options indisponible en stable. J'ai une tonne d'exemple du genre, les problèmes de dépendances et tout ..
[^] # Re: C'est dommage
Posté par mickabouille . Évalué à 2.
Pourquoi garder un historique linéaire ?
Et pourquoi les paquets devraient passer par unstable en période de freeze ? La règle générale (passage automatique unstable->testing) est déjà modifiée de toute façon.
Dès le freeze, on se retrouve virtuellement avec testing=unstable. Dans ce cas, pourquoi avoir deux noms différents ?
Et depuis quelque temps, sont apparus des outils qui permettent un truc épatant, le développement avec plusieurs branches.
[^] # Re: C'est dommage
Posté par anaseto (site web personnel) . Évalué à 5.
Eh bien, moi j'ai debian stable sur un portable que je n'utilise pas beaucoup, ça m'évite de perdre du temps avec quand j'en ai besoin (j'utilise un fixe avec openbsd le reste du temps).
[^] # Re: C'est dommage
Posté par Adrien . Évalué à 5.
Perso j'utilise Debian stable dans un contexte professionnel, sur des postes utilisateurs. Et ça se passe très bien.
[^] # Re: C'est dommage
Posté par Anonyme . Évalué à 1.
Il me semble qu'il existait un projet visant à maintenir la continuité de testing après son gel, seulement je ne parviens pas à retrouver de la documentation dessus et je ne sais pas si ce projet est toujours d'actualité ou non.
Cela dit, il ne me semblait pas que Sid était également gelé lors du gel de Testing, Pour avoir utilisé Sid pendant un moment, il m'a toujours semblé que les paquets continuaient à arriver dedans sans que la migration vers Testing ne se fasse tout bêtement.
[^] # Re: C'est dommage
Posté par François (site web personnel) . Évalué à 5.
Moi j'utilise stable en desktop au travail et chez moi. Parce qu'au travail mes outils sont ainsi configurés pour plusieurs années et je ne perds pas de temps à réapprendre. Chez moi car ainsi je ne passe pas de temps à refaire fonctionner une configuration qui ainsi ne bouge pas pendant plusieurs années. Et ma femme est ainsi heureuse. De plus avec les backports je peux avoir plus récent pour les logiciels populaires.
En fait la seul chose qui me pousse à testing c'est avoir matplotlib pour python3.
[^] # Re: C'est dommage
Posté par Sylvain Briole (site web personnel) . Évalué à 2.
J'utilise stable depuis plusieurs années, aussi bien pour les rares installations sur des machines à usage professionnel, que sur toutes mes machines à la maison.
Les raisons:
1. moins je passe de temps à administrer mes machines, mieux je me porte
2. même si les logiciels ne sont pas les derniers sortis, ils correspondent parfaitement au besoin
[^] # Re: C'est dommage
Posté par gpe . Évalué à 1.
Au boulot j'utilise stable + backports pour éviter qu'une mise à jour de testing rende non fonctionnel quelque chose qui marchait précédemment comme ça arrive régulièrement.
[^] # Re: C'est dommage
Posté par wilk . Évalué à 3.
J'utilise stable depuis des années, sur serveur et machine de dev/maison. Quel repos de ne pas avoir à se soucier de stabiliser l'instable !
En revanche, s'appuyer sur du stable ne veut pas dire que l'on ne doit utiliser que du stable. Le tout est de définir ce qui doit être exceptionnel. Je préfère avoir quelque chose de stable par défaut et exceptionnellement changer (à l'aide de backports, virtualenv, vm…) que l'inverse avoir de l'instable pour tout et d'être obligé de stabiliser ce qui le nécessite.
En python j'utilise virtualenv, car les besoins sont différents, très peu de paquets à gérer et que je connais parfaitement, dans ce cas ça me permet d'avoir du stable, encore plus que debian (que je n'ai pas forcément à mettre à jour lors d'une maj debian), ou inversement d'utiliser des versions très récentes (mais que je maîtrise, ce qui ne serait pas possible avec tous les éléments d'une distribution).
En plus le principe du gel permet de faire le point sur la cohérence de la distribution. Il facilite également le support, l'installation de nouvelles machines, le développement etc.
Il permet inversement d'être plus à l'aise avec les versions non stables puisqu'elles le sont explicitement.
[^] # Re: C'est dommage
Posté par barmic . Évalué à 4. Dernière modification le 12 novembre 2014 à 15:52.
Moi ! Je met du Debian stable sur toutes mes machines et je passe ma machine principale à testing lors d'une sortie des préversion de l'installeur pour tester la mise à jour et faire un retour d’expérience éventuel, le reste de mes machines passe à la nouvelle stable dans le mois qui suit sa sortie.
J'ai peu besoin des dernières versions de logiciel et quand j'en ai besoin je les installe à la main dans
/opt(pour intellij et maven par exemple) ou via un dépôt quand il y en a un qui va bien (pour firefox et chrome principalement).Du coup mon système est divisé en 2 :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est dommage
Posté par khertan . Évalué à 2.
[^] # Re: C'est dommage
Posté par cluxter . Évalué à 0.
Je retourne la chose : ceux qui utilisent Debian en dehors de la branche Stable n'ont rien compris à Debian et feraient mieux d'utiliser Ubuntu (ou de lire la suite de mon commentaire ;-) ).
Je m'explique.
La branche Stable est, ô miracle, stable. C'est celle qui est utilisée partout en production. Elle est sécurisée, fiable, maintenue. Mais les versions des logiciels sont figées (pour avoir une stabilité dans le temps, donc une cohérence de l'ensemble sur une période donnée, en l'occurence environ 2 ans).
Si l'on souhaite mettre à jour des paquets, on utilise les rétroportages (= backports en anglais). Ce sont des paquets qui sont officiellement (depuis le 05 septembre 2010 : https://www.debian.org/News/2010/20100905 ) maintenus par l'équipe Debian et qui permettent d'avoir des versions plus récentes des paquets les plus utilisés sans pour autant déstabiliser le système, que ce soit en termes de sécurité, de stabilité ou de performances. Parmi eux, on peut noter : le kernel, LibreOffice, Firefox (= Iceweasel), Thunderbird (= Icedove), VLC,…
La branche Testing est à destination des développeurs et constitue une sorte de Beta de Debian. On l'utilise si l'on souhaite voir à quoi ressemblera la prochaine version de Debian, ou pour contribuer au développement de la future version, ou parce qu'on souhaite utiliser vite fait et très salement un truc qui ne se trouve pas dans Stable et qu'on ne veut pas casser son système de base (auquel cas on peut l'utiliser via un 'chroot', ou dans une machine virtuelle, ou en dual boot temporaire). C'est une version dont la stabilité et les performances ne sont évidemment pas garanties, mais bien plus important que ça, la sécurité n'est pas garantie (puisqu'elle fait l'objet de tests et d'ajustements constants). C'est donc une branche à proscrire pour toute utilisation sur un réseau (ce qui inclut l'Internet, et même surtout sur l'Internet) ou pour toute machine qui se doit d'être stable et/ou sécurisée.
La branche Unstable (nommée Sid) est également à destination des développeurs, mais là ça ressemble carrément à une version Alpha de Debian. Autant dire que la sécurité laisse à désirer. Quant à la stabilité, n'en parlons pas.
Enfin, le dépôt Experimental n'est même pas une branche, c'est un vaste dépotoir dans lequel on place quelques paquets pour ceux qui souhaitent tester si un truc tout nouveau qui vient de sortir a une chance de ne pas foutre en l'air tout le système complet (genre 'wayland' v0.1 ou 'systemd' v0.1). C'est pour voir comment le système réagit à l'ajout de paquets assez particuliers. Ca correspond à une version prototype de Debian.
Lorsque Debian Testing est en phase de gel, on peut dire qu'elle n'est plus en version Beta mais en version admissible (= Release Candidate). Ce qui, là encore, n'est pas censé être utilisé sur une machine de tous les jours.
J'ai envie de dire que d'une certaine façon seuls ceux qui ne sont pas assez compétents utilisent autre chose qu'une branche Stable sur une machine de tous les jours. Car ceux qui sont suffisamment bons sauront comment compiler un programme et l'adapter si jamais il ne tourne pas d'origine sur la Stable, et comment chrooter une Testing ou une Unstable dans une Stable pour la tester et/ou contribuer au développement. Les seuls cas où l'on devrait utiliser une Testing ou une Unstable directement sur une machine, c'est lorsqu'on souhaite contribuer au code de Debian.
Finalement, Canonical ne fait rien d'autre que de mettre beaucoup de mecs à temps plein sur une Debian Testing pour virer un maximum de bugs le plus vite possible, de proposer vite fait des logiciels additionnels et d'appeler tout ça 'Ubuntu'. A mon sens, ils feraient mieux d'allouer ces ressources directement au développement des backports et des branches Testing et Unstable. Ca permettrait de passer Debian en Stable beaucoup plus vite, d'avoir des backports bien plus nombreux et plus fiables et d'élargir la compatibilité de Debian avec les nouvelles machines.
Néanmoins c'est plus ou moins le cas depuis un petit moment, je sais que les développeurs d'Ubuntu et de Debian travaillent plus en collaboration qu'avant et ça se ressent dans le développement de Debian (pas toujours dans le bon sens malheureusement).
[^] # Re: C'est dommage
Posté par xcomcmdr . Évalué à 5.
Euh… C'est totalement faux. Déjà au départ (soit en 2004) Ubuntu (qui a pris énormément de développeurs Debian à l'époque) c'était pour proposer une Debian plus user-friendly (ce qui a permis à Debian de s'améliorer de ce côté là, même s'il y a encore une nette différence avec Ubuntu), notamment au travers de l'installeur et de l'orientation de la distribution vers le 'desktop' et les utilisateurs venant de Windows.
Par ailleurs, ça fait longtemps que Ubuntu ne se base plus sur Testing, car il y a énormément de logiciels (pas uniquement ceux venant de Canonical ou de sa communauté) qui ne sont pas sur les dépôts Debian (tiens rien que pour Xubuntu : xfce4-volumed-pulse, les indicator-plugins*, …) ou pas intégrés de base (la différence entre une Debian + Xfce et Xubuntu est juste abyssale en termes d'utilisabilité et d'ergonomie).
Bref, la description d'Ubuntu ce serait plutôt :
- une distribution utilisant le format .DEB mais ayant ses propres dépôts / paquets depuis longtemps
- 5 ans de support pour les LTS de Ubuntu/Kubuntu (3 ans pour celles de Xubuntu et Lubuntu). C'est plus que Debian Stable, et c'est le plus gros intérêt pour moi. ;-)
- des PPAs (et non, rajouter un PPA Ubuntu sur Debian n'est pas une bonne idée) permettant d'avoir des logiciels plus récents que sur les dépôts Ubuntu
- des tonnes de distributions dérivées (Ubuntu Studio par exemple, qui propose aussi des LTS)
- son propre environnement de bureau (Unity)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est dommage
Posté par nonas . Évalué à 6.
Je ne connais pas Xubuntu mais je tiens à préciser que Xfce sur Debian, c'est géré activement par une personne (Yves-Alexis Perez) ! Merci à lui parce que c'est parfaitement utilisable au quotidien.
[^] # Re: C'est dommage
Posté par Adrien . Évalué à 2.
Il me semble que Ubuntu récupère environ 70% des paquets de Debian, sans modification. Il reste donc 30%, qui sont soit repacakgé, soit des nouveaux logiciels.
[^] # Re: C'est dommage
Posté par barmic . Évalué à 8.
T'es mignon. Je crois pas qu'il y ai de vidéo des minidebconf française, mais je me souviens qu'à la dernière l'un des membres de la release team avait commencé sa conférence en demandant à l'assistance qui utilisait stable, testing et experimental. L'énorme majorité de l'assistance utilisait testing, sachant qu'au milieu des badauds comme moi, il y avait plusieurs DD, 2 DPL (l'actuel et un précédent) et le conférencier. J'ai comme un doute sur le fait que ces gens là n'ont "rien compris à Debian"…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est dommage
Posté par cluxter . Évalué à 1.
Tu parles de personnes qui mettent les mains dans la cambouis pour debugguer Debian là. Donc on est bien d'accord : la Testing est faite pour ceux qui sont suffisamment à l'aise pour remonter les bugs et contribuer au développement de Debian.
Ma phrase est assez radicale et volontairement provoc, je l'admets.
A part un groupe d'ubergeeks prêts à casser du bug, je ne vois pas l'intérêt d'utiliser une Testing sur un poste de travail pour faire du montage vidéo, pour surfer, pour faire de la bureautique,…
[^] # Re: C'est dommage
Posté par barmic . Évalué à 5.
1 an après la sortie de stable la testing commence à montrer la différence sur du matériel très récent. J'ai quelque installations depuis un an sur du matériel très récent (des portables avec la dernière famille de CPU intel) et l'installation était technique avec stable et triviale avec testing (si je me souviens bien les problèmes venaient surtout de l'EFI et des partitions).
Donc, non des fois il faut être un ubergeek pour faire une installation de stable sur du matos à la noix et madame michu pour installer testing.
Pour ce qui est de la sécurité même s'il faut le prendre au sérieux. Je pense qu'il faut surtout se concentrer sur le web pour un poste client. Donc avoir un navigateur et flash à jour. Les attaques sur les autres logiciels sont déjà très rares avoir une faille 2 ou 3 jours plus longtemps (c'est à dire 16 à 24h si tu utilise ta machine 8h par jour) ce n'est pas forcément énorme (surtout si comme pour shellshock tu te la trimbale déjà depuis 20 ans).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est dommage
Posté par Anthony Jaguenaud . Évalué à 3.
Je confirme cela, néanmoins, pour être tranquille, j’ai opté pour le kernel et les firmwares en backports, et le reste en stable.
[^] # Re: C'est dommage
Posté par cluxter . Évalué à 1.
De même, j'ai eu affaire à une machine extrêmement récente et la Stable ne fonctionnait pas (carte mère mal supportée, notamment la partie graphique). J'ai installé le dernier kernel disponible dans les backports et plus aucun problème.
Sur une machine classique, la Testing n'apporte rien de plus que les backports d'un point de vue système (puisque les backports sont généralement alignés sur la Testing !). Pareil pour tout ce qui est bureautique.
Sur une machine plus exotique (avec des périphériques de montage vidéos spéciaux par exemple), c'est autre chose. Tout ce qui touche au multimédia a tendance à nécessiter des logiciels récents, donc dans ce cas je comprends que la Testing puisse être nécessaire.
Une autre raison d'utiliser la Testing, c'est si on a absolument besoin d'un élément mis à jour comme 'wayland' ou 'systemd'. Là on touche au coeur du système et les backports ne peuvent pas faire le boulot. C'est selon moi le seul cas où on pourrait être amené à utiliser une Testing "en production".
[^] # Re: C'est dommage
Posté par Moonz . Évalué à 1.
Heu, systemd est dans les backports…
[^] # Re: C'est dommage
Posté par cluxter . Évalué à 2.
Donc ça confirme d'autant plus l'inutilité de la Testing sur un poste de travail autrement que pour débugguer la future version de Debian =)
Si la Stable avec des backports est capable de faire la même chose que la Testing pour 95 % des logiciels qu'on utilise, pourquoi vouloir utiliser une branche instable et moins sécurisée ? Je ne vois pas de raison objective à cela (si ce n'est, je me répète, pour contribuer au débuggage de la future Debian).
[^] # Re: C'est dommage
Posté par barmic . Évalué à 3.
Personnellement c'est l'installation du bootloader qui ne s'était pas bien passé (mais sans erreur visible, juste ça ne marche pas). Une technique c'est utiliser une autre distro live (testing par exemple) pour faire une réinstallation de grub après coup. C'est pas démesuré mais c'est pas trivial.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est dommage
Posté par Cyril Brulebois (site web personnel) . Évalué à 2.
Les vidéos sont disponibles sur : http://meetings-archive.debian.net/pub/debian-meetings/
J'ai aperçu mini-debconf-paris pour 2012 mais pas pour 2014. J'avoue ne pas me souvenir si c'était filmé et le cas échéant s'il manque « juste » une manip sur les vidéos et un upload.
Debian Consultant @ DEBAMAX
# Enlightenment 0.17
Posté par alendroi . Évalué à 9.
Etant utilisateur de ce bureau sous Wheezy, tu as oublié de souligner que E17 est présent dans les dépôts Jessie, ce qui est quand même une petite révolution pour les utilisateurs de Debian.
Dire que vous vous n'en avez rien à faire de la vie privée parce que vous n'avez rien à cacher, c'est comme dire que vous n'en avez rien à faire de la liberté d'expression parce que vous n'avez rien à dire. Edward Snowden
[^] # Re: Enlightenment 0.17
Posté par Aissen . Évalué à 8.
On en est juste à E19.1 ;-)
https://tracker.debian.org/pkg/e17
http://enlightenment.org/p.php?p=download&l=en
[^] # Re: Enlightenment 0.17
Posté par reynum (site web personnel) . Évalué à 4.
Justement e19 viens de sortir, e18 a 1 an environ et Debian ne propose que e17, d'où le commentaire sarcastique (je pense) de "alendroi"
Alors je ne sais pas quel travail cela représente de packager un DE mais ne même pas avoir e18 dans unstable je trouve ça dommage.
Quand je vois à quelle vitesse à été proposé "Maté" je me dis que le packageur de "e" devrais passer la main ou déléguer du travail car manifestement il n'a pas le temps (ou pas assez) de participer.
kentoc'h mervel eget bezan saotred
[^] # Re: Enlightenment 0.17
Posté par Aissen . Évalué à 2.
Je ne suis pas sûr qu’alendroi était si sarcastique (on ne sait jamais sur Internet, n’oubliez pas vos smileys avec votre sarcasme)
Cela dit je suis d’accord que la co-maintenance pourrait fortement aider les mainteneurs de paquets en général. À voir si quelqu’un veut filer un coup de main, et si la collaboration peut marcher.
[^] # Re: Enlightenment 0.17
Posté par claudex . Évalué à 4.
J'aimerais bien savoir comment tu arrive à la conclusion que les mainteneurs de e ne veulent pas déléguer alors que les faits (absence de proposition d'aide par exemple) montre plutôt qu'ils n'attendent que ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Enlightenment 0.17
Posté par reynum (site web personnel) . Évalué à 2. Dernière modification le 15 novembre 2014 à 12:39.
Je ne donne aucun exemples car je n'en ai pas, ce n'est qu'une supposition basée sur l'observation que seul e17 est présent dans Debian alors que e18 a presque un an.
Je n'incrimine pas je constate juste que ça ne va pas vite (pour ne pas dire lentement) et que je trouve ça dommage car j'aimerais beaucoup tester e19, en effet je cherche un nouveau DE pour mon laptop perso. Hier j'ai essayé pendant 2 heures de l'installer dans une VM KVM sur Debian Wheezy avec ce script sans résultats autre que négatifs.
Des fois je me dis que j'aimerais beaucoup me mettre à faire des packages Debian et des fois moins.
Bref, quoi qu'il en soit merci pour le travail qu'ils fournissent déjà et bon courage pour la suite.
kentoc'h mervel eget bezan saotred
[^] # Re: Enlightenment 0.17
Posté par alendroi . Évalué à 1.
Tu devrais plutôt essayer de compiler E19 sur Jessie. Je n'ai jamais réussi à faire démarrer E19 sur Wheezy.
Dire que vous vous n'en avez rien à faire de la vie privée parce que vous n'avez rien à cacher, c'est comme dire que vous n'en avez rien à faire de la liberté d'expression parce que vous n'avez rien à dire. Edward Snowden
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.