The Gram Code Editor - 2026-03-23


  1. thedoctor

    > Now there is a flatpak available for the 1.1.0 release, but I feel like way to install flatpaks is via Flathub or some other repository.. I started looking at submitting it, but haven't completed that yet. Flathub is definitely the way to go. I think that requires a source package, though. I'm still only starting getting my feet wet with all the packaging stuff.

  2. thedoctor

    > Yes, I couldn’t build the flatpak in a regular container because it needs fuse. Will try to make a flatpak build later when I have time to wrestle with it As a temporary solution you could build the flatpak and AppImage locally and upload to releases manually?

  3. krig

    Hi :)

  4. krig

    Yes I will try to build an appimage.. but I think I need to set up a build server on Hetzner or something, the builds are taking too much time on my old computer 😅 right now I think I will tag 1.2.0 before I manage to produce an appimage for 1.1.0

  5. thedoctor

    > Yes I will try to build an appimage.. but I think I need to set up a build server on Hetzner or something, the builds are taking too much time on my old computer 😅 right now I think I will tag 1.2.0 before I manage to produce an appimage for 1.1.0 You need to install `pkg2appimage` which is a bash script and make it available to the `bundle-linux` script via env var or in $PATH but once that works the rest works pretty well, in my experience. Also, it doesn't need to build anything, it just converts an existing .deb package. But I know, it's a lot

  6. krig

    ah, cool, so it needs the deb built.. thanks! Oh I have a question actually.. the generate-rpm package takes a huge amount of time with no output.. any idea what it’s doing? from the docs it looks like it should’t be rebuilding anything

  7. thedoctor

    > ah, cool, so it needs the deb built.. thanks! Oh I have a question actually.. the generate-rpm package takes a huge amount of time with no output.. any idea what it’s doing? from the docs it looks like it should’t be rebuilding anything It doesn't rebuild, I think it takes all that time compressing the package.

  8. thedoctor

    If you think it's worthwhile, we could choose a different (or no) compression to save time.

  9. thedoctor

    If you think it's worthwhile, we could choose a different (or no) compression algorithm to save time.

  10. krig

    I see.. yeah my machine is slow too. I’ll try a different compression and see if that helps

  11. thedoctor

    On my machine, RPM compression with zstd takes 15 minutes, without compression 2 seconds. The other algorithms may be in the middle. I researched Debian packaging a while and came to the conclusion that creating a source package for OBS or a PPA would be nontrivial because neither Debian nor Ubuntu have a package for the needed Rust version, regardless of version. A binary package is fairly simple in comparison but OBS and launchpad don't accept these, it seems so we'd have to self-host such a repo

  12. krig

    now that we have deb, rpm, flatpak and appimage I think we’re good enough.. I just need a better runner, but that’s coming

  13. nicoco

    I have _some_ experience hosting debian repo on codeberg for my stuff

  14. nicoco

    If I have a look at uploading the .deb to it, would you be interested?

  15. nicoco

    I would certainly love to have my gram updates handled by my usual `apt update && apt upgrade` workflow

  16. krig

    Oh yeah that would be great!

  17. nicoco

    alright. we can even have two "components", eg, "release" and "bleeding-edge" if the .deb is built on every push, but that requires some (little) additional plumbing, to automatically generate a valid version number. I'll start with attempting the basic "release" repo.

  18. krig

    I think having just stable packages fits the development model for gram better to be honest, at least right now.. bleeding edge is probably going to be both disappointingly slow and likely to break 😅

  19. thedoctor

    > I have _some_ experience hosting debian repo on codeberg for my stuff How does that work, exactly?

  20. Patrick

    https://forgejo.org/docs/next/user/packages/debian/?

  21. Patrick

    https://forgejo.org/docs/latest/user/packages/debian/?

  22. krig

    There is a PR to add a flatpak repository too which should be merged soon I hope

  23. nicoco

    > > I have _some_ experience hosting debian repo on codeberg for my stuff > > How does that work, exactly? You PUT the .deb to a URL then you get https://codeberg.org/slidge/-/packages/debian/slidge/

  24. thedoctor

    I see, I didn't know Codeberg had this capability. How does signing the packages work? Does the server side take care of that or do you have to upload a signature?

  25. nicoco

    > I think having just stable packages fits the development model for gram better to be honest, at least right now.. bleeding edge is probably going to be both disappointingly slow and likely to break 😅 counter argument: having a "bleeding edge repo" gets you more testers and feedback to make releases better. but anyway, let's start with the basic "release" one :)

  26. krig

    👍

  27. nicoco

    > I see, I didn't know Codeberg had this capability. How does signing the packages work? Does the server side take care of that or do you have to upload a signature? handled by codeberg

  28. thedoctor

    > handled by codeberg In that case, it should be fairly trivial to upload RPM and DEB packages to the repos packages automatically after building them and that should be that, yes?

  29. nicoco

    indeed

  30. nicoco

    hmmm yaml killed me for today, I can't decipher why I cannot run this test action: https://codeberg.org/nicoco/gram/actions/runs/5/jobs/0/attempt/1 Line: 14 Column 9: Failed to match job-factory: Line: 69 Column 15: Failed to match run-step: Line: 71 Column 15: Unknown Property uses I'm running on `codeberg-tiny` runners to test instead of `rust-amd64` because I guess that's a private runner you set up krig

  31. nicoco

    Could it be why I'm getting these mysterious errors? We'll know tomorrow, because I have to go play some roguelike deckbuilding video game for now. Priorities!

  32. krig

    ah yeah my runner is my old gaming pc in my basement 😄 I can take a look later and see if I can figure it out

  33. thedoctor

    > hmmm yaml killed me for today, I can't decipher why I cannot run this test action: https://codeberg.org/nicoco/gram/actions/runs/5/jobs/0/attempt/1 > Line: 14 Column 9: Failed to match job-factory: Line: 69 Column 15: Failed to match run-step: Line: 71 Column 15: Unknown Property uses > I'm running on `codeberg-tiny` runners to test instead of `rust-amd64` because I guess that's a private runner you set up krig You're trying to have "uses" and "run" in the same step, that's not valid.

  34. krig

    Hm, I think I am giving up on appimage for now.. can’t get it to build in CI or on my local machine :/