Heads-up from the OpenMandriva camp: a messy disagreement between contributors apparently escalated into deliberate damage. The project says one person used administrative access to delete code and push a harmful placeholder package — the kind of stunt that could wreck users’ installs if left unchecked.

What actually happened

In short: a contributor who had special access removed pieces of the project’s work on GitHub and uploaded an empty package to the development repository that effectively replaced packages for two desktop environments. The team calls this more than a mistake — they say it was intentional and damaging, timed after heated arguments and some people leaving the project.

  • The contributor reportedly had admin rights because they helped mirror and migrate repositories to a private instance.
  • Using those privileges, parts of long-running repositories were deleted rather than moved or archived.
  • An obsoleting package was published that would supersede the affected desktop packages — potentially harmful to people updating from the development branch.

Aftermath, denials, and the cleanup

OpenMandriva says it’s restoring what was deleted and running a full system audit to catch any other sneaky changes. The person blamed denies trying to sabotage the distro, calling their actions deliberate but aimed at addressing disagreements over which desktops the project prioritizes. The developer claims some collaborators had deleted build configuration files first, and that their deletions were a reaction, not an attack.

The project team described the deletions as potentially criminal but opted not to open a legal case. Instead they’re rebuilding repositories, checking package integrity, and tightening access so that a single disgruntled account can’t wreak havoc again.

Quick context: OpenMandriva is a community-run Linux distribution that branched off from Mandriva years ago. One of its quirks is that it compiles most of its stuff with the LLVM/Clang toolchain rather than the more common GCC — nerdy but interesting.

Takeaway? Open-source projects look friendly, but they still need good access controls, clear communication, and backups. When people argue publicly and permissions are scattered across personal machines, things can get ugly fast. If you run a project, assume someone will press the big red button one day — then make sure it won’t do much harm.