#1147732 RFS: neofetch/7.1.0-3 [ITP] -- Shows Linux System Information with Distribution Logo #1147732
- Package:
- sponsorship-requests
- Source:
- sponsorship-requests
- Submitter:
- Joaquin Daniel
- Date:
- 2026-10-18 05:27:01 UTC
- Severity:
- normal
Dear mentors, I am looking for a sponsor for my package "neofetch": * Package name : neofetch Version : 7.1.0-3 Upstream contact : Dylan Araps <dylan.araps@gmail.com> * URL : https://github.com/dylanaraps/neofetch * License : Expat * Vcs : https://salsa.debian.org/debian/neofetch Section : utils The source builds the following binary packages: neofetch - Shows Linux System Information with Distribution Logo To access further information about this package, please visit the following URL: https://mentors.debian.net/package/neofetch/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/n/neofetch/neofetch_7.1.0-3.dsc Changes since the last upload: neofetch (7.1.0-3) unstable; urgency=medium . * Reintroduce package (Closes: #1147637) * Update Standards-Version to 4.7.4.1 * Switch to debhelper-compat level 13 * Update Maintainer to new maintainer Regards,
Neofetch is dead upstream and has been archived since 2024. fastfetch exists and does the job well. Closing. If you re-open, please give a really good reason for re-introducing. Sorry, Simon
Hi Simon, Thanks for reviewing the RFS ticket. I would like to request reopening this ticket based on community demand and my commitment to maintaining the package within Debian. While fastfetch is indeed the modern alternative, neofetch remains an iconic tool with massive adoption, especially for users migrating from older releases (like Ubuntu 22.04) and legacy setups where existing scripts specifically rely on neofetch. Although upstream is archived, I am willing to take full responsibility as the package maintainer in Debian, handling downstream patches and compatibility fixes as needed to ensure it meets Debian Quality Assurance standards without adding technical debt. As proof of active maintenance and packaging work, I am currently maintaining and building the package successfully for the Fedora ecosystem via COPR: https://copr.fedorainfracloud.org/coprs/daniopenhat/neofetch/ Given the ongoing demand from the community and my commitment to maintaining downstream patches, I kindly ask to reconsider re- introducing neofetch. Best regards, Dani (Joaquín)
Hi Simon, Here is the "really good reason" you asked for to re-introduce neofetch. While it is true that fastfetch is the modern, actively maintained alternative, it does not cover the exact use case that a significant portion of our user base relies on. My argument for re-introduction is based on three pillars: 1. The "Legacy Migration" Factor: Many users migrating from older releases (like Debian 11 or Ubuntu 22.04) are accustomed to `neofetch`. More importantly, there are thousands of legacy scripts, dotfiles, and tutorials in the wild that explicitly call `neofetch`. Forcing them to switch to `fastfetch` breaks their workflows. Keeping neofetch allows for a seamless transition and backwards compatibility. 2. The "Emergency/Low-Level" Diagnostic Tool: Neofetch is a pure Bash script. Unlike compiled binaries (which can fail if a shared library is broken or if the graphical environment fails to load), a Bash script relies on basic system commands. If a user's system breaks, the network manager fails, or they lose their graphical interface, `neofetch` is a lifeline to quickly check kernel version, DE/WM, and hardware state without needing a browser or complex tools. It is a reliable, universal diagnostic tool. 3. My Commitment as a Maintainer: I am not asking Debian to adopt an orphaned package. I am taking full responsibility for it. As proof of my active maintenance, I am already building and maintaining this package successfully for the Fedora ecosystem (including Fedora 43, 44, and Rawhide) via COPR: https://copr.fedorainfracloud.org/coprs/daniopenhat/neofetch/ I am fully prepared to handle any downstream patches, fix compatibility issues, and ensure it meets Debian Quality Assurance standards, without adding technical debt to the archive. The community still wants it, and I am ready to do the work. I kindly ask you to reconsider this re-introduction. Best regards, Dani (Joaquín)