3 ms·
$100 to a Debian Developer who can get Fresh Editor into Trixie
I use Debian 13 in a regulated industry and I'm teaching people how to code in the context of large projects and TUI.
I want to use Fresh Editor (https://getfresh.dev/). This is because Fresh is easier to learn quickly than vim & emacs, and more of an IDE than micro & nano, and more favorable for compliance auditing because of its core-and-plugins architecture and open source code using Rust.
I would like to donate toward this goal. I can afford to offer $100 to any Debian Developer who has the suitable skill and trust to accomplish this. The software author must say yes too, of course.
Success looks like this: create a new Debian 13 server, type "apt install fresh-editor", and it works. No third-party apt sources needed, because I have compliance reasons. Fortunately Fresh already has a *.deb file and explains it on the Fresh installation page.
Here's the GitHub issue:
https://github.com/sinelaw/fresh/issues/2169
I'm not affiliated with Fresh in any way, just a early adopter user. If you view the GitHub issues, I'm also offering $100 each for helping with Fresh display issues on MacBooks, and for adding Fresh ePub capabilities.
I'm doing this because I believe in funding open source as much as possible.
- ahsgdfh 4mo agoThis isn't going to happen. Debian Trixie has already been released. The packages going into Trixie were frozen on April 25, 2025. If you want a new package in the official Debian repos, it needs to be packaged for Unstable, then promoted to Testing, then eventually Testing will be cut as a Stable release. The next Testing freeze will probably be sometime next year.
- jph 4mo agoGood info, thank you. I'll aim for the next version with $100 to get it into Debian 14. <3
- atsaloli 4mo agothank you for creating gitalias, very useful!
- jph 4mo agoYou're welcome, thanks for the shout out. Glad it's helping you. <3
- the__alchemist 4mo agoOut of the loop: Why not run this, from the top of the home page: curl https://raw.githubusercontent.com/sinelaw/fresh/refs/heads/master/scripts/install.sh https://raw.githubusercontent.com/sinelaw/fresh/refs/heads/m... | sh IMO this isn't part of your OS; it's cross-platform PC software. Install it using the bin its creators have provided. They have even built and are hosting a Deb for your linux distro (From inspection of the script)
- jph 4mo agoI see in your posts that you do a lot with Rust and biology. Broadly, the same way you can use the tool "cargo install" to fetch a bunch of dependency crates from one source and be sure their versions can all run well together and update together, I can use the tool "apt install" to do the same for applications. The concept is called a "package manager" and it greatly helps me achieve a concept called "reproducible builds", as I gradually migrate the work toward a package manager for reproducible builds called "Nix". https://en.wikipedia.org/wiki/Package_manager https://en.wikipedia.org/wiki/Package_manager https://en.wikipedia.org/wiki/Reproducible_builds https://en.wikipedia.org/wiki/Reproducible_builds https://en.wikipedia.org/wiki/Nix_(package_manager) https://en.wikipedia.org/wiki/Nix_(package_manager)
- the__alchemist 4mo agoThat is some attention to detail in your research! I appreciate the explanation and examples. I think perhaps I am deliberately dodging the OP's question, treating it as an X/Y problem. He or she mentioned compliance as a valid reason, but it still feels like a smell: I think the original software could be installed using the provided deb, or building from source by cloning the repo and running `cargo run` on a Debian or Ubuntu system older than or the same version as the one he intends to use. (A Rule of Thumb I've found works well for Debian!) I recognize that a lot of Linux users like the package system. I think it's a great tool for software that's intended to be integrated with the OS, but is a bit of a mismatch for third-party software. The creators here have even build a .deb, which is above and beyond. (Compared to, for exmple, compiling a +x linux executable that has been tested on Debian) So, from a writer and user of software, I think I would rather publish the executables or a script to install them on my website (as they have done) for all the major OS branches, and as a user, I think c+ping and launching the CLI command they provided front and center is fantastic. It's an above-avg experience; a trivial install process, which isn't a given for OSS.
- hlieberman 4mo agoHello! I am a Debian Developer, though not likely to work on this as I haven't done a ton of rust binary packaging. I did want to clear up one misconception that you might be having, though. The .deb versions shipped by upstream are great, but they're not really ever going to be useful for Debian. One of the side-effects of Debian's requirements around software freedom is an important principle: you should be able to build any package in Debian with only the things that are in Debian. The problem with fresh isn't fresh itself -- packaging that isn't particularly difficult, though it does need some amount of care and attention. The problem is that fresh pulls in 732 different crates which all need to be packaged in Debian before fresh can be. Some of them are already in Debian, of course, but... you can imagine that the effort here is very much not insignificant. Upstream doesn't have to deal with this problem, as they can simply statically build them into the executables. That's a violation of Debian policy, though, and isn't allowed for anything in the archive. Hope that helps you understand why you may not get many bites at this offer, generous as it is!
- jph 4mo agoExcellent info thank you. Your explanation makes perfect sense, and leads to the security compliance info that I'm reading. I'm seeking to stop supply chain attacks as described at https://wiki.debian.org/Rust https://wiki.debian.org/Rust Could there potentially be a way for a program to include all the source code of all its dependencies, at least for any that aren't on Debian?
- MeltedVoltage 4mo agoThe problem that Debian has with rust packages is that they try to apply handling a C-style dependency chain (usually only a few C libraries with large scope) for the rust crate ecosystem (a lot of dependencies with small scope). Having to maintain 732 just for one release of a new package is not sustainable. I don't understand why the policy is not: pulling all crate sources and prepackaging into a tar with associated licenses. The source tree then is part of the package which can still be built from source and gets linked statically.
- hlieberman 4mo ago
- late_night_fix 4mo agoThis feels like a good example of open source economics.A relatively small amount of money can create value for everyone who used Debian in the future.