Forum

Reprise du message précédent

Déjà installé sur mon mediacenter kodi qui tourne sous mageia 8

Il n'y a pas de nouvelle Cauldron. Il n'y a pas un nouvel ISO. Le développement de Mageia étant ouvert, il s'agit juste de la version en cours dans laquelle les packagers poussent les paquets et les font évoluer. Ça peut aussi permettre à un développeur tiers de commencer à modifier ses programemes pour qu'ils fonctionnent sur la prochaine Mageia dès sa sortie et aux développeurs Mageia d'avoir un environnement pour tester les outils pour la future version. Contrairement à d'autres distributions, la Cauldron n'est pas fermée ou accessible uniquement sur inscription.

Dit autrement : un rapport de bogue peut être utile directement upstream, à destination des développeurs de CodeBlock, mais n'a que peu d'intérêt sur le Bugzilla de Mageia.

Si c'est le cas, je ne remonte plus les bugs. Mais, je tourne sur Cooker puis Cauldron depuis 15 ans au moins. Je n'ai jamais eu trop de problèmes.

On ne dit pas qu'il ne faut pas remonter de bogues. Mais il faut différencier un bogue de quelque chose de normal dans le cycle de développement. Et il vaut mieux les posters sur bugs.mageia.org plutôt qu’ici. Si tôt dans Cauldron, il faut attendre que les paquets soient recompilés. Les pacakgers peuvent aussi désactiver temporairement certaines fonctionnalités des logiciels en attendant qu'ils trouvent un correctif. Ils sont donc déjà au courant du problème. Code::Blocs ou Eclipse sont des programmes assez haut dans la chaine des programmes. Il est donc normal qu'ils ne soient pas tout à fait fonctionnels si tôt dans le développement.

En effet, tu peux avoir très peu de problèmes. Mais rien ne peut empêcher un gros problème arrivant un jour. De plus, un problème peut rester pendant plusieurs semaines ou mois car ce n'est pas urgent de corriger Caudlron. J'ai deux VM pour tester les nouveaux Plasma et GNOME, je ne les utiliserait pas pour autre chose.

C'est un peu radical, tu ne trouves pas ?



Tant mieux alors ! Mais je trouve qu'il est quand-même important de faire la différence entre un bug qui est lié à un problème de packaging chez Mageia, plutôt qu'un bug qui relève de l'équipe de développement du logiciel.
Par exemple, j'ai pu faire un jour le comparatif entre des éléments qui, pour une même version de Musescore, présentait un défaut d'affichage chez Mageia, défaut que j'ai pu constater car je ne le voyais pas avec la même version de Musescore sur une autre distrib : c'est typiquement le genre de rapport de bug qu'il faut mettre sur notre bugzilla. Si ça avait été un bug de Musescore lui-même, constaté sur le même numéro de version installé sur deux distrib différentes, le rapport de bug aurait été plus utile directement là où les dev de l'appli vont pouvoir en prendre connaissance. Tu penses pas ?

Tu me dis que ça ne sert à rien...

Si ça sert, je continue à les remonter à Mageïa, c'est ma modeste contribution qui doit faire faire rire les anglophone avec mon anglais de vache espagnol.
Sinon, je retourne peut-être plus souvent sous la version stable !

Aujourd'hui code::blocks marche. Mais, je ne travaille pas...

Classique !

Bonjour, toujours remonter ce qui ne fonctionne pas. C'est mieux, même quand ça touche Cauldron.

Mais à la limite, il faut TOUJOURS s'attendre à des bugs et des choses cassés. Idéalement, suivre la ML "dev" où des annonces sont faites quand quelque chose est poussée comme par exemple la bascule vers python 3.9.

De plus, quand on remonte un bug sous Cauldron, il peut parfois être utile de vérifier si la version stable est aussi touchée. Si elle l'est aussi, sa résolution peut être aussi accélérée. Un bug Cauldron est moins prioritaire que pour une stable.

Bonsoir

Je sais que je joue avec le feu avec Cauldron. Quand c'est cassé, si ça me gêne, c'est après moi que je râle si ça ne marche pas. Si je veux que ça marche, j'ai qu'à rester sous la version stable.
Si c'est cassé, je me débrouille pour faire autrement, je sais faire depuis le temps. Mais, comme je sais ce que je fais, j'ai moins de problème que d'autres (que je ne nommerai pas) qui utilise la version stable sans savoir exactement ce qu'ils font. À force de maintenir d'autres PC, j'ai parfois l'impression que ma version de développement est plus stable!

Donc, je reste sous Cauldron si ça sert de remonter les bug. Après, passer sous stable pour tester quand Cauldron boge, ce n'est pas toujours pratique, les configurations ne sont pas toujours compatibles.

HAhahahaha

En fait, il y a "bogue et bogue". Tout n'est pas bon à remonter, ou alors il faut remonter lorsqu'un bogue persiste dans le temps.
Je ne suis pas certain que le forum MLO soit la meilleure place pour ça, trop peu d'empaqueteur sont francophones, et les francophones ne suivent pas vraiment le forum... J'en connais deux... Seulement deux qui suivent le forum MLO et qui sont empaqueteurs Mageia.Org.
Je fais toujours mon apprentissage empaquetage, bientôt nous serons 3

Troumad, je pense qu'il doit y avoir un moyen plus efficace pour contribuer à votre niveau.
Ce qui j'imagine en premier, ça serait de lister les besoins dans votre cas professionnel. Si je me souviens bien, vous avez mentionné de vieilles carte de dev. Par exemple, que manque-t-il pour compiler/flasher ses cartes ?
(Et mon rêve, fournir une Mga avec une liste de logiciels à installer avec urpmi, et tous les cours sont possibles sans windows )

Je remonte mes problème sur bugzilla et je les partage ici.
Je ne me souviens de problème de cartes de dev. Peut-être qu'il y a longtemps, j'ai posté un problème d'un collègue, eux peuvent en utiliser. Mais, ils n'utilisent pas mageia.
J'ai eu un problème avec Ride (un vieux logiciel windows, peut-être ça dont tu parles) dont l'éditeur sous wine n'affichait pas les caractères. C'est comme si on écrivait en blanc sur blanc. Mais, ce n'était pas un problème cauldron, c'était au moins un problème mageia.

nb : on peut se tutoyer. Non ?

On commence par ça, OUI !

Pour moi, l'utilisation de Wine (et de Ride) est le problème. Est-ce qu'on parle de ça : https://www.st.com/en/development-tools/ride-stm32.html ?
Connais tu openOCD ? http://openocd.org/ (Free and Open On-Chip Debugging, In-System Programming and Boundary-Scan Testing)
LibOpenCM3 ? https://libopencm3.org/ (Open-Source lowlevel hardware library for ARM Cortex-M3 microcontrollers (but also M0, M4 are supported and more to come) )
Je vais m'en faire des paquets prochainement.

À l'IUT, on a une vieille carte avec un vieux microcontrôleur qu'on cherche à changer, mais on ne trouve rien... Le matériel à plus de 20 ans, mais d'un point de vu pédagogique, rien n'est valable pour ce qu'on veut faire.
Donc, on fait tourner du vieux matériel avec des vieux logiciels en attendant de trouver ce qu'on veut en espérant que nos antiquités tiendront. On était déjà heureux de voir que ça tournait avec widows XP, ça tourne encore avec windows 10.

Quels-sont les besoins ?
Pourquoi c'est si spécifique ? (Car des solutions et des dev-board, il y en a une flopée)
Quelle est la carte exactement ?
Est-ce que je peux me la produire (pour tenter de le faire exclusivement sous linux) ?
Un développement lent en interne par les étudiants n'est pas envisageable ?
(DUT GEII ?)