<apostolis>Yes, I have used nixos before, but I haven't used guix.
<Sharlatan>apostolis roots are the same and priciple either :)
<Sharlatan>str1ngs so after each `git pull` I need to run all build process again? and after any changes I've added, mhm..
<str1ngs>Sharlatan: make will only build changed files. though there is a limit to that. like if new files where added etc
<str1ngs>Sharlatan: for the most part make should be enough to build subsequent changes
<apostolis>I just downloaded 3 versions of guix, probably due to different dependencies (?!?)
<str1ngs>Sharlatan: also it might easier to have a branch with your changes and re-base your branch from master after pulling. this way your changes are applied on top. it's easier to deal with conflicts this way.
<Sharlatan>thanks str1ngs probali I need to prepare multicore VM as it takes more than 40m to build Guix on T420 :-D
<str1ngs>Sharlatan: after running make were you able to build your package?
<ecbrown>ok, got past the stdlib error, thanks to recipe found in mpd.scm
<apteryx>hmm... seems there's no safe way to implement a srfi-9 record -> alist converter, as the record's getter names can have arbitrary names and after the record is created it keeps no knowledge itself about those; so the best we can do is look at the bounded symbols in the scope and guess...
<apteryx>maybe the way to go would be to augment the record definition and bind the converter at expansion time, where we know what is what
<ng0>hey, so if anyone wants to give packaging it a shot, https://github.com/slicer69/doas is claimed to work with the Linux kernel. I just tested the package I finished for it in pkgsrc-wip. That's the sudo equivalent worked on by OpenBSD.
<efraim>ng0: that is pretty cool, I'm interested to add it to my todo list
<efraim>ng0: oh, question about your rust packaging, are you grabbing all the sources to compile in one go or have you figured out something with dynamic libraries?
<ng0>I don't have that much insight yet, I'm working on getting that insight.. the gist is we name all crates used from Cargo.lock, throw them in a vendor path, patch the Cargo.toml to use that vendor path instead and (by default) don't allow any fetching of cargo in the build env. so you could say we grab them all in one go
<ng0>the .crate files end up in the global distfiles
<ng0>efraim: how do you treat the resulting .crates.toml which ends up in the root of what's pointed to? I know you don't have this problem in guix at first, but when updating the profile it would end up potentially being ignored because only 1 of those can exist in the profile root
<ng0>having shared builds instead of vendoring every time would be so nice
<ng0>I've spend so much time building the same libs again and again
<bmwiedemann1>rekado: I was wondering, if there was progress towards a guix-packages.json
<chrislck>Is there a GUIX FAQ somewhere? trying to wrap head around it, rather difficult
<quiliro>chrislck: just the manual...what are you looking for?
<chrislck>the manual is not too clear unfortunately. on top of the hurdle of installing it correctly, (1) while piggybacking onto ubuntu what are the folder names and what used for? how to remove guix cleanly?
<chrislck>(2) using guix as a dev or as a user -- what's the difference? (3) i'm doing guix install guile-next which is running >20mins -- why????
<chrislck>(4) i find mistake/old package and wish to update - who/where is the package maintainer?
<chrislck>etc -- a bit steep for a beginner!!! mind you I'm comfortable in guile, just not guix
<chrislck>the manual is unfortunately a marketing blurb... tells me all the benefits of guix (which I believe) but rather scant on actual day-to-day usage
<chrislck>it seems a mix of docker/snap/flatpak/virtualenv
<quiliro>chrislck: i do not know all the answers, but what the manual says is 1) /gnu/store holds all the installed packages and there are some directories in /var named guix...there is also .guix-profile...there is an archwiki entry where it shows how to remove guix...probably the same on other systems..it is very easy
<quiliro>2) a user becomes closer to a dev in guix...but i am not sure if that is your question...please clarify
<chrislck>(2) if I do $guix install emacs-guix -- does it mean I'm an emacs user, or I'm setting up to hack on emacs source?
<chrislck>does it always need to compile from source?
<quiliro>3) if there are substitutes (some sort of binaries), installation will be quick... but not always substitutes are available and even if they are, not all systems are alike, so some compilation is required to make your system exactly as mine (reproducible)
<quiliro>2) that means that user has emacsguix installed for that user only...but emacs-guix is for doing several installation and hacking tasks for packages also
<quiliro>it does not always need compilation as long as what you propose installing is what others have installed exactly the same way...there is adependency graph that is taken even to the versions or compilation tags of the programs
<chrislck>others = other users on the same machine you mean... if I'm the only user then I always expect to compile from sources?
<quiliro>4) bugs are reported on the firstname.lastname@example.org mailing list if it is something guix related...if not, you can use 'guix package --show=emacs' to show the website of the software
<quiliro>others= other users such as you of that guix package server
<minall>I would like to package it but... Can it definition be simple like the one in 'a guix packaging tutorial' blog?... I doubt it is that simple, for example, the definition for openjdk seems complicated