Lector de Feeds

Potions in Mageia. 05 – How Mageia ranks amongst the best ‘user-friendly’ distros, even though many people aren’t aware of it.

Blog de Mageia (English) - 28 Septiembre, 2026 - 14:00

This week, we’ve been concocting a potion using a few ingredients provided by our brilliant team of developers and packagers. The way applications are managed and packaged in Mageia, compared to other competitors, makes system management and software usage very straightforward for our users. The implementation of graphical tools such as the Mageia Control Centre forms an important part of the system, but what is not widely known is how certain applications are packaged compared to other systems, how the inclusion of plugins and software extras for applications is handled, and how dependencies are managed throughout the packaging process. Let’s get started!

Conceptual Principles

Mageia has inherited and refined the Mandriva/Mandrake packaging philosophy; our aim is to deliver ‘ready-to-use’ applications, without skimping on optional features or add-ons. Other distributions tend to package applications in their lightest version, leaving out plugins or add-ons, which forces the user to search for extra packages. In Mageia, we often include plugins, integrations and multimedia support directly within the application or under a single metapackage.

Mageia is characterised by an integrated packaging philosophy: rather than splitting a programme into multiple sub-packages or applying strict licence restrictions in the main repository, Mageia’s maintainers compile the software with as many extensions, filters and hardware support features enabled by default as possible, provided these add extra functionality to the application and are approved by the packaging team.

Our installer

In Mageia 10, we currently have URPMI (User RPM Installer), which is our default package manager and the backbone of both the graphical and terminal-based application installation processes, although native support for DNF (now DNF5) is also included.

URPMI has a number of advantages over its competitors, such as:

  • It uses very lightweight summary files containing only the data essential for resolving dependencies, allowing repositories to be queried or refreshed almost instantly, even on slow connections.
  • It does not need to store the full description and information for each package locally unless required, saving disk space in the indexes.
  • One of its greatest advantages is not just the command line, but the fact that the graphical package manager ‘rpmdrake’ shares the same engine. In other managers, the graphical tools act as independent wrappers that sometimes conflict or do not reflect the same statuses of orphaned packages.
  • Urpmi has spent decades refining its algorithm for detecting orphaned packages left behind after uninstalling an application, adapting it to Mageia’s RPM package structure; this prevents critical system libraries from being uninstalled by mistake during the clean-up process.

DNF has also been enabled in Mageia due to a number of modern features:

  • Transaction history.
  • Modules and AppStream. Better integration with modern software repositories.
  • Active upstream support. It is maintained directly by the rpm.org project.

Some urpmi commands in the terminal:

  • urpme: to remove packages.
  • urpmq: to list packages.
  • urpmf: to search for packages containing specific files or capabilities.
  • urpmi: for installation and updates.


A brief diagram

At Mageia, through our repository sections, we package versions of programmes that are compiled from day one with support enabled for, for example, all networking modules, streaming protocols and hardware-accelerated video, as well as numerous proprietary or obscure image formats that other distributions move to secondary repositories or remove altogether. End-user convenience is prioritised over strict ‘purity’ in packaging; provided that an add-on makes the packaged application more useful, this is largely due to the official ‘Tainted’ repositories dedicated to software subject to patents or legal restrictions in certain countries, which allow applications to be packaged in their full version without restricting functionality.

Mageia maintains the build infrastructure, dependencies, policies and controls to ensure that the packages form a coherent system.

A clear example of this is the “gimp-plugin-astronomy” package, which remains available for installation until the end of support for Mageia 9. Although it is no longer maintained by its creators, Mageia has continued to provide it for our users until the release of GIMP 3.0, with which it is no longer compatible due to the switch to Python 3.

Some other examples:

  • LibreOffice. In other distributions, it is packaged as separate components, and features such as icon themes, database integration or desktop environments are omitted.
  • Inkscape. In Mageia, it includes a dependency map that enables, by default, all extensions for mathematical rendering, bitmap processing and the import/export of CAD files, without the need to search for other Python libraries.
  • Audacity, VLC, Kodi. Through the various repositories, they are packaged with support enabled for features that do not appear in other distributions.
  • Pidgin. We’ve already discussed this application elsewhere. The Mageia package is very comprehensive, featuring many plugins and messaging protocols not found in other distributions.


A vision for packaging in Mageia

Behind the packaging process, there are defined policies and review procedures through which we aim to ensure the software fits into the system, rather than simply distributing the packages as published by the developers.

Some key features of our packaging:

  • Python. Clear conventions, pyproject, noarch, documentation and dependencies managed by RPM:
  • Java. We avoid duplicate JAR dependencies and maintain separation of components.
  • Firefox. Main package and separate translations. The required language is installed based on the system language.
  • LibreOffice. Installation of the entire suite and the required language based on the system language, in a single metapackage, or separate installation of individual applications.
  • Libraries. Separation of runtime, development and dependencies.
  • KDE/Qt applications. Specific policies for names, libraries and components.
  • Licences. We maintain separation of licences via the ‘Core/Nonfree/Tainted’ repositories.
  • Updates validated by the QA team before reaching the stable release.

What does all this mean for the user?

Most of these decisions do not appear in a screenshot. They do not, on their own, make Plasma’s animations better or cause Firefox to open any faster.

Their value becomes apparent in more everyday situations:

  • Installing an application and automatically obtaining the correct dependencies.
  • Uninstalling it without leaving behind stray files.
  • Updating a library without ending up with multiple incompatible copies.
  • Installing only the languages we need.
  • Installing documentation only when we’re interested in it.
  • Having separate development packages.
  • Maintaining a consistent software base.
  • Receiving updates that have gone through a validation process.

In other words, our users don’t have to constantly think about packaging. If the job is done properly, it simply works.

Conclusions

The main strength of our packaging lies in the way all our teams work together to ensure that each programme fits seamlessly into the whole.

Packaging policies, the separation of components, the handling of dependencies, the careful management of third-party libraries, licence management and the quality control process all form an integrated and coherent system.

The work carried out by our packaging, development and quality assurance teams, whilst not visible to our users or the general public, is one of the most important factors in making our distribution a truly stable and reliable Linux distribution. A great deal of engineering work goes into ensuring that everything fits together to achieve the final result.

Categorías: Blogs Oficiales

MGASA-2026-0457 - Updated erlang package fixes security vulnerabilities

Mageia Security - 27 Septiembre, 2026 - 04:12
Publication date: 27 Sep 2026
Type: security
Affected Mageia releases : 10
CVE: CVE-2026-54886 , CVE-2026-54891 , CVE-2026-54892 , CVE-2026-54893 , CVE-2026-55952 , CVE-2026-55953 Description
SSH SFTP server denial of service via extended channel data infinite loop. (CVE-2026-54886) Plaintext APPLICATION_DATA injected during TLS handshake delivered to client application post-handshake in ssl. (CVE-2026-54891) Plug: quadratic-time decoding of nested query/body parameters enables denial of service. (CVE-2026-54892) Email-derived URL path injection in the Swoosh Microsoft Graph adapter. (CVE-2026-54893) References
SRPMS 10/core
  • erlang-27.3.4.17-1.mga10

MGASA-2026-0455 - Updated python3 & python-pip package fixes security vulnerabilities

Mageia Security - 26 Septiembre, 2026 - 16:57

MGASA-2026-0453 - Updated udisks2 package fixes a security vulnerability

Mageia Security - 25 Septiembre, 2026 - 17:24
Publication date: 25 Sep 2026
Type: security
Affected Mageia releases : 10
CVE: CVE-2026-7867 Description
Local privilege escalation via as-user option spoofing. (CVE-2026-7867) References
SRPMS 10/core
  • udisks2-2.10.1-3.1.mga10

MGAA-2026-0137 - Updated libalkimia package fixes bug

Mageia Security - 25 Septiembre, 2026 - 17:24
Publication date: 25 Sep 2026
Type: bugfix
Affected Mageia releases : 10
Description
Conflicting file between Mageia 9 and Mageia 10 versions of the package can block upgrades to Mageia 10. This update fixes the reported issue. References
SRPMS 10/core
  • libalkimia-8.2.1-1.1.mga10

Fin de soporte para Mageia 9

Blog de Mageia-ES - 25 Septiembre, 2026 - 08:07

En Mageia, hemos completado un hito importante con el lanzamiento de Mageia 10 el 30 de Junio de 2026. Ha sido un paso importante de modernización de nuestro sistema en muchos aspectos, y nuestro caldero ya comienza a cocer para cocinar nuestra próxima versión Mageia 11!

Mageia 9 ha sido sólida como una roca, con 24008 actualizaciones hasta el momento, correcciones de seguridad para nuestros usuarios. Esto se traduce en un arduo trabajo de todos nuestros equipos que hacen que Mageia sea fácil y segura.

Llega el momento de decir adiós a nuestra novena versión y centrarnos en los nuevos retos que propone el mantenimiento de Mageia 10, el desarrollo de Mageia 11 y la adecuación de nuestro software a nuevos tiempos para que soporte las últimas incorporaciones tanto de hardware como de software de terceros empaquetado para nuestros usuarios de Mageia.

Esperamos que todo el trabajo realizado por nuestros colaboradores determine un gran sistema de código abierto de uso fácil, moderno y actualizado para toda nuestra comunidad. Puedes encontrar las características completas de Mageia 10 en las notas de lanzamiento.

El soporte para las versiones previas se extiende a 3 meses después del lanzamiento de la versión más reciente por lo que Mageia 9 dejará de tener soporte el próximo 30 de Septiembre. Por lo tanto, te pedimos que si no lo has hecho ya, consideres migrar a Mageia 10, ya que el soporte para Mageia 9 terminará con las últimas actualizaciones que han sido validadas.

Los métodos de migración se pueden realizar mediante:

  • La aplicación de actualización a versiones mayores de Mageia en la bandeja del sistema (actualmente icono azul de actualización).
  • Usar la línea de comandos como se describe en las notas.

También es posible migrar a Mageia 10 con una instalación limpia mediante las imágenes de instalación clásica. Las imágenes Live pueden usarse para probar Mageia 10 o hacer una instalación limpia, pero no son compatibles para realizar una migración/actualización a la nueva versión de Mageia.

Ten en cuenta que al realizar una instalación limpia, cualquier información no guardada en una partición separada o en una copia de seguridad en un dispositivo externo, será borrada. Comprueba que has realizado los respaldos apropiados.

Si tienes alguna pregunta o necesitas ayuda con la migración, puedes recurrir a nuestros foros que abarcan la mayoría de los idiomas o en el wiki de Mageia.

Categorías: Blogs Oficiales

End of Support for Mageia 9

Blog de Mageia (English) - 25 Septiembre, 2026 - 08:07

At Mageia, we have reached a significant milestone with the release of Mageia 10 on 30 June 2026. It has been a major step towards modernising our system in many respects, and our cauldron is already beginning to simmer as we prepare our next release, Mageia 11!

Mageia 9 has been rock-solid, with 24,008 updates to date, providing security fixes for our users. This is down to the hard work of all our teams, who ensure that Mageia remains easy to use and secure.

The time has come to say goodbye to our ninth release and focus on the new challenges posed by the maintenance of Mageia 10, the development of Mageia 11, and adapting our software to the changing times so that it supports the latest additions in both hardware and third-party software packaged for our Mageia users.

We hope that all the work carried out by our contributors will result in a great open-source system that is user-friendly, modern and up-to-date for our entire community. You can find the full list of features for Mageia 10 in the release notes.

Support for previous versions extends to 3 months after the release of the latest version, so Mageia 9 will no longer be supported as of September 30. We therefore ask that, if you have not already done so, you consider upgrading to Mageia 10, as support for Mageia 9 will end with the latest validated updates.

Migration can be carried out using:

  • The update application for major versions of Mageia in the system tray (currently the blue update icon).
  • Using the command line as described in the notes.

It is also possible to migrate to Mageia 10 with a clean install using the classic installation images. Live images can be used to try out Mageia 10 or perform a clean install, but they are not compatible for migrating to or upgrading to the new version of Mageia.

Please note that when performing a clean install, any data not stored on a separate partition or backed up to an external device will be deleted. Please ensure you have made the necessary backups.

If you have any questions or need help with the migration, you can visit our forums, which cover most languages, or the Mageia wiki.

Categorías: Blogs Oficiales

MGASA-2026-0452 - Updated python-webob packages fix a security vulnerability

Mageia Security - 25 Septiembre, 2026 - 06:02
Publication date: 25 Sep 2026
Type: security
Affected Mageia releases : 10 , 9
CVE: CVE-2026-44889 Description
Location header normalization during redirect leads to open redirect - again References
SRPMS 10/core
  • python-webob-1.8.11-1.mga10
9/core
  • python-webob-1.8.11-1.mga9

MGASA-2026-0451 - Updated unbound packages fixes security vulnerabilities

Mageia Security - 25 Septiembre, 2026 - 06:02
Publication date: 25 Sep 2026
Type: security
Affected Mageia releases : 10 , 9
CVE: CVE-2026-14586 , CVE-2026-32665 , CVE-2026-40622 , CVE-2026-40691 , CVE-2026-41637 , CVE-2026-42955 , CVE-2026-44621 , CVE-2026-44687 , CVE-2026-44690 , CVE-2026-46582 , CVE-2026-50045 , CVE-2026-50046 , CVE-2026-50243 , CVE-2026-50248 , CVE-2026-50251 , CVE-2026-50252 , CVE-2026-52863 , CVE-2026-54478 , CVE-2026-55708 , CVE-2026-55717 , CVE-2026-55973 , CVE-2026-55990 , CVE-2026-55991 , CVE-2026-56416 , CVE-2026-56444 , CVE-2026-77860 , CVE-2026-77955 , CVE-2026-78227 , CVE-2026-80225 , CVE-2026-81634 , CVE-2026-81642 , CVE-2026-82717 , CVE-2026-82720 , CVE-2026-85501 Description
Heap buffer overflow and possible Remote Code Execution when digesting DNSKEY Possible heap buffer overflow during DNSSEC canonicalization CNAME synthesis could lead to heap corruption Possible ZONEMD verification bypass window Use-after-free in DoQ stream output buffer on reset re-transmission Possible degradation of service from continuous queries on the same TCP/DoT connection Use-after-free in DoH stream cleanup code path Retrap: Novel Vulnerabilities to launch Algorithmic Complexity Attacks on DNSSEC 'serve-expired' can bypass Unbound 'wait-limit' Remote DNS-over-QUIC denial of service due to 'quic-size' budget bypass Packet of death for DNSCrypt over TCP Cross-zone wildcard cache poisoning via RRSIG.labels manipulation 'dns-error-reporting: yes' leads to stack buffer overflow Assertion in libngtcp2 when under pressure in high concurrency DNS-over-QUIC environments Libunbound applications configured with 'unwanted-reply-threshold' could eventually be abruptly terminated 'max-global-quota' reset by DNSSEC validation restarts Possible heap use-after-free in an error path when a DoT forwarded query is jostled out 'response-ip'/'rpz' can rewrite BOGUS answers instead of returning SERVFAIL BOGUS configured primary hostname accepted for XFR in auth/rpz zones Date: Attacker supplied '0.0.0.0'/'::' glue triggers defensive full-cache flush Possible cache poisoning attack by mapping source port population per thread Memory corruption could lead to crash and denial of service 'serve-expired-client-timeout' and 'response-ip' CNAME redirect could lead to a crash Packet of death for a DNSCrypt misconfigured Unbound Remote DNS-over-QUIC (DoQ) flow-control assertion failure in libngtcp2 Possible heap buffer overflow when validator canonicalizes RDATA that contains domain name Degradation of resolution service when 'discard-timeout' and 'serve-expired-client-timeout' are combined in unusual configuration Degradation of resolution service from improperly accounted client-terminated DNS-over-QUIC queries Extra fix for CVE-2026-40622 to also clamp the TTL of A/AAAA records disallowing a one-time 'ghost domain' delegation renewal via glue records Off-by-one error in 'harden-below-nxdomain' logic can shadow a stub/forward zone by a legitimate parent's NXDOMAIN A wildcard replay, as another piece of data, triggers poisoning in the serve expired reply path DNS Cookie bypass when combined with proxy-protocol use Privacy/configuration issue when adding local data in views through 'unbound-control' Possible arbitrary code execution during DNSSEC validation Heap overflow with multiple NSID, COOKIE, PADDING EDNS options Crash during DNSSEC validation of malicious content Date: Packet of death with DNSCrypt Another "ghost domain names" attack variant Long list of incoming EDNS options degrades performance Jostle logic bypass degrades resolution performance Degradation of service with unbounded NSEC3 hash calculations Possible cache poisoning via promiscuous records for the authority section Unbounded name compression in certain cases causes degradation of service Use after free and crash under special conditions in RPZ code Possible domain hijacking via promiscuous records in the authority section Cache poisoning via the ECS-enabled Rebirthday Attack Unbounded name compression could lead to Denial of Service Unbound vulnerable to the "DNSBomb" pulsing DoS amplification attack Denial of service when trimming EDE text on positive replies DNSSEC verification complexity can be exploited to exhaust CPU resources and stall DNS resolvers NSEC3 closest encloser proof can exhaust CPU Non-Responsive Delegation Attack Novel "ghost domain names" attack by updating almost expired delegation information Novel "ghost domain names" attack by introducing subdomain delegations Local symlink attack Vulnerability in Domain Parse NXNSAttack Vulnerability in IPSEC module Vulnerability in parsing NOTIFY queries Vulnerability in the processing of wildcard synthesized NSEC records No limit to delegation chaining Ghost domain names attack Incorrect proof processing for NSEC3-signed zone Processing of duplicate CNAME records in a signed zone Empty error packet handling assertion failure References
SRPMS 10/core
  • unbound-1.26.1-1.mga10
9/core
  • unbound-1.26.1-1.mga9

MGASA-2026-0450 - Updated python-gitpython packages fix security vulnerabilities

Mageia Security - 25 Septiembre, 2026 - 06:02
Publication date: 25 Sep 2026
Type: security
Affected Mageia releases : 10 , 9
CVE: CVE-2026-87819 Description
Denial of Service via catastrophic backtracking (ReDoS) in Actor.name_email_regex — commit author/committer field parsing Repository content can impersonate the git directory, leading to arbitrary code execution Residual of GHSA-hmq2-w58f-27jc: the fix validates the `.gitmodules` **name** but the sibling **path** field still reaches `os.makedirs()` unguarded, although GitPython already owns the containment guard References
SRPMS 10/core
  • python-gitpython-3.1.62-1.mga10
9/core
  • python-gitpython-3.1.62-1.mga9

MGAA-2026-0136 - Updated discover package fixes start-up bug

Mageia Security - 25 Septiembre, 2026 - 06:02
Publication date: 25 Sep 2026
Type: bugfix
Affected Mageia releases : 10
Description
In systems that don't have plasma as the desktop discover fails to start. This update fixes the reported issue. References
SRPMS 10/core
  • discover-6.5.5-4.1.mga10

Cooker

Blog de OpenMandriva - 25 Septiembre, 2026 - 00:58
Cooker (development)

Cooker is the OpenMandriva Lx development branch.

This is where developers do the actual work of developing packages and the distro itself. Because of the nature of this continual work process Cooker breaks at times.

If you are not used to problem solving on computers at a very high level Cooker is not for you.

  • arrow_drop_downCOOKER Plasma

    The Plasma Extended version is basically a complete desktop for most non-technical users. It features software from KDE.org and other Qt based software. It includes software for most day to day tasks.

Donate

Blog de OpenMandriva - 25 Septiembre, 2026 - 00:58
Welcome to OpenMandriva!

We are a community-driven initiative dedicated to fostering open source innovation in the realm of operating systems. Since our inception, we have been committed to creating a user-friendly, cutting-edge Linux distribution that empowers users worldwide. However, to continue our mission and enhance our offerings, we need your support.

Why Donate?

Your donations play a crucial role in sustaining and advancing the OpenMandriva project. With your generous contributions, we can:

Downloads

Blog de OpenMandriva - 25 Septiembre, 2026 - 00:58

OpenMandriva flagship release is ROME (rolling)

Current Rock release is OpenMandriva Lx 6.0

Development release is Cooker

Spins are alternative desktops environments

Choose your release The OpenMandriva project offers different image types available for download.
If in doubt, use the full featured Plasma6 x86_64 ISO image. Download the ISO file

Mirror download (sourceforge.net)
Enter the folders, select the release in the list, it should automatically open a download page from a mirror nearby your location.
If in doubt, go to OpenMandriva homepage at SourceForge and click the big green button “Download”

Frequently asked questions

Blog de OpenMandriva - 25 Septiembre, 2026 - 00:58
Questions and Answers
  • arrow_drop_downTell readers about the founding of Open Mandriva This is essentially just old history - maybe the most interesting part is that it means we are one of the oldest distributions still alive today.
    When Mandriva (previously Mandrake) went out of business, the community didn’t want to let the distribution die, so it was turned over to a team consisting of previous contributors, and people from related similar projects (Unity Linux, Ark Linux) joined forces to form OpenMandriva.
    We agreed with what remained of Mandriva on terms for all further development:
    License
  • arrow_drop_downWhat does OpenMandriva inherit from Mandrake? Technology? Organization? Philosophy? The original source code;
    The initial team, or part of it;
    The idea of building an operating system that is simple enough for someone who has never seen Linux to get productive with, without dumbing it down to the point that it stops being useful to experts.
    OpenMandriva philosophy is inspired by the Open Source principles philosophy.
  • arrow_drop_downAny stats about downloads, commits, developers? Given we are an Open Source project with quite a few mirrors and bittorrent downloads, and we have no idea how many people share their download with others, it is impossible to get accurate numbers.
    We can get documented stats only from SourceForge mirror. Maybe worth to mention that many users and/or newcomers are invited to download and test the latest ISO images snapshots, during development cycle in-between the officially announced releases, directly from our build server, ABF (cf. Forum topics Most recent Cooker ISO and Most recent ROME (rolling) ISO which we keep constantly up-to-date).
    Of course we have more accurate numbers about developers and commits.
    There are 7 main developers, and a few people who submit a patch once in a while.
    There have been 82350 commits in the last year, out of which 7323 were in the last month.
    The commits go to our repositories OpenMandriva Association and OpenMandriva Software and the packages are built on ABF: [1] [2]
  • arrow_drop_downHow is OpenMandriva organized, and how are decisions made? OpenMandriva has 2 main entities:
    Council for what concerning the legal/paperworks, PR and organization side;
    Technical Committee for what concerning the products’ technical development side.
    The decisions are made depending on the specific subject however more often than not they are virtually identical pertaining to both sides.
    When at all possible we aim to reach consensus for final decisions. Crucial help is provided by the shared target and common sense.
    People who have been contributing consistently over some time are invited into the relevant entities.
  • arrow_drop_downHow does the Association interact with the community?
    • Main website /
      (News)

Get involved

Blog de OpenMandriva - 25 Septiembre, 2026 - 00:58
Give time

If you have time, we welcome your help in various areas:

Development

Check the developers documentation, join the conversation, and have a look at the bug-tracking system and to get in touch with the developers community and get things done

Writing

Help us improve the documentation, materials and communication

Translation

Translators, help us translate web materials, OpenMandriva Lx and other projects

Keep the Community alive

Participate in the forum, write your experience with Rock or ROME, share your knowledge, publish your desktop screenshots, help the other users, or even just chat

Rock

Blog de OpenMandriva - 25 Septiembre, 2026 - 00:58

Rock (OMLx 6.0) is the home and workstation edition published by the OpenMandriva Association. Also for individual users who do not want many updates, be it because they prefer their system to remain the same or because of slow internet connection. Releases are scheduled around once a year.

It would be the most stable and suitable for users that like things to stay as they are and just work. Package upgrades will be limited mostly to bug fixes, and security updates.

ROME

Blog de OpenMandriva - 25 Septiembre, 2026 - 00:58

ROME is the rolling edition, designed for individual users.

It is designed to be a working, usable system and will have the most up to date packages.

ROME users should be familiar with the command line or terminal (Konsole) and be able to use it at times.

  • arrow_drop_downPlasma 6

    The Plasma Extended version is basically a complete desktop for most non-technical users. It features software from KDE.org and other Qt based software. It includes software for most day to day tasks.

Feed