urbanists.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
We're a server for people who like bikes, transit, and walkable cities. Let's get to know each other!

Server stats:

543
active users

#guix

14 posts13 participants0 posts today

Hello all, here's my #introduction post. I migrated here from #fosstodon. This instance feels more aligned to my values.

I'm a software developer and a long time Linux/#FOSS user. I maintain packages in #Fedora, but recently been also packaging software for #guix.

I'm interested in #meditation, #ethics and #sustainability in computing and in real life, more on the side of doing than posting about it.

I also enjoy art a lot, good books, music, movies and visual art.

If you have questions, feel free to ask. If not, have a nice day 🥰.

Well, I've gone and done it. Barely been using my "daily driver" laptop lately, because I default to the cheap spare I set up #Guix on. No more! The former Debian install has been backed up, the machine wiped, and Guix installed.

Was about to attempt to package #GHDL for #Guix... spent an hour before I stumbled across the guix-electronics[1] channel!! I know there's a channel aggregator somewhere but I always forget to check it before making a package...

Funny that it isn't upstreamed yet though. GHDL seems like a package that would fit into Guix proper very well, we have a `fpga.scm` file already anyway. Perhaps its accomodating all the different compile-time variations?

[1] git.sr.ht/~csantosb/guix.chann

https://ultrarare.space/en/posts/guix-rust-packaging-preview/

On the next merge of
rust-team branch, Guix will support importing Rust dependencies from the generated lockfile Cargo.lock. A simplified Rust packaging model utilizing the new feature will be introduced, and a workflow will also be documented in Guix Cookbook (bug#77093: New Rust packaging workflow based on lockfile importer).

To test the new packaging model and tweak the workflow, in the past two weeks I have migrated 150 Rust programs, with a total amount of 3638 dependencies and slightly higher source expectation. You might be amazed if you have ever tried Rust packaging in Guix.

More details will be covered in a future blog post on
Guix Blog.

This post is to share you the news and give a
very brief instruction on how to use the lockfile importer in your own channel at the moment.

Wait, at the moment...? Yes! Build system changes from
rust-team branch are not hard requirements.

#guix #rust

Ultra Rare Space · Previewing the New Rust Packaging Model for GuixOn the next merge of rust-team branch, Guix will support importing Rust dependencies from the generated lockfile Cargo.lock. A simplified Rust packaging model utilizing the new feature will be introduced, and a workflow will also be documented in Guix Cookbook (bug#77093: New Rust packaging workflow based on lockfile importer).\nTo test the new packaging model and tweak the workflow, in the past two weeks I have migrated 150 Rust programs, with a total amount of 3638 dependencies and slightly higher source expectation. You might be amazed if you have ever tried Rust packaging in Guix.\n
Replied in thread

@Edent The #guix version is at 3.62.2, and seems to work okay. Guix is way better than flathub if you can tolerate the time to do the delta upgrade computations and then the initial package download.

For the uninitiated:

* install #guix through your operating system installer
* run 'guix pull' at the command line
* run 'guix shell filezilla -- filezilla'

Voilà!

Replied in thread

@michaelcoyote NixOS is decades old.

share the issue you’re having.

I feel that NixOS is unparalleled but it takes dedication.
Once something works, it just works; delivers what Docker pretends to.

For me, flakes allow me to lock in my dev env & builds.

That said, I can’t help but think that #Nix is the precursor to something ideal.
The only thing standing in Nix’s way is the stack they chose long ago.
IMO, Nix being untyped was a mistake.

#GUIX#Sixos#nickel

I couldn't do it. I went back to #nixos #guix is lovely in premise. I like the idea of a general purpose language, especially #scheme driving it, but the documentation is fucking TERRIBLE! And I already have a robust nixos config. Configuring the damned thing was keeping me away from doing shit.

Hey #Guix! The Guix Consensus Document (GCD) about « Migrating repositories, issues, and patches to #Codeberg » will close soon!

The last version:

git.savannah.gnu.org/cgit/guix

Discussion: issues.guix.gnu.org/76503

Drop a comment: mailto:76503@debbugs.gnu.org

Thanks all the participants and @civodul for driving; a friendly debate even on a touchy topic = a nice outcome! 😀

git.savannah.gnu.org002-codeberg.md - guix/guix-consensus-documents.git - Guix Consensus Documents

Was messing about in Debian land over the weekend, and it's made me really appreciate some #Guix stuff:

- Guix packages get rebuilt when their dependencies change. Was trying to use the arm64 Guix .deb, and it doesn't work, spewing errors about incompatible bytecode. That wouldn't happen on Guix, because it'd get rebuilt if Guile changed.

- Building any package in Guix is as simple as `guix build package`. Trying to rebuild the .deb to fix the first problem required a ton of screwing around and manually installing stuff on the system including installing devscripts to run a program to make a fake package with build-deps, which you then install (or in my case, install, find that didn't work, uninstall, then reinstall a different way) to get the environment to build the thing.

Guix ain't perfect, but these problems simply don't exist there.