<lle-bout>raghavgururajan: telling the *what* is not very useful in commit messages or comments, I am not sure whether the *why* should be located in commit messages or comments, I tend to do a bit of both, comments for when that's relevant to someone reading the code, commit message when it's more relevant to someone reading the history, sometimes a bit of both when it's a bit of the two
<lle-bout>raghavgururajan: One question I have is about the xorg servers used in tests, it never quits, does it get killed automatically?
<raghavgururajan>I was under the impression that it gets killed at the end of build process. Did you notice otherwise?
<lle-bout>raghavgururajan: in many cases the spirit of your current commit messages works fine, e.g. "small" changes with not much impact besides the thing it's changing itself, but I am thinking for such core packages it might be important to explain more there
<lle-bout>raghavgururajan: I didnt notice otherwise but it puzzled me!
<raghavgururajan>I started to do more comments, may be I should do it more. Thanks for the feedback. Will do.
<lle-bout>raghavgururajan: If not Guix, maybe this GNOME upgrade, but glad to know about it! I am happy that's the case! Because we can't afford giving up because else core-updates will remain broken in ways that nobody else will be able to fix.
<lle-bout>raghavgururajan: We have time though, so no rush!
<lle-bout>After the 1.2.1 release I am hopeful we'll get help!
<lle-bout>raghavgururajan: thanks a lot for your work, I need to go sleep now!
<link2xt>looks like cargo-build-system can only vendor dependencies from crates-io, but not from git
<link2xt>if there are git dependencies, .cargo/config should also have an entry for each of them
<jgomo3>I thought the package emacs-recutils would add the rec-mode. It is not happening for me. Is there another package which add rec-mode to emacs?
<jackhill>jgomo3: it used to, but I guess it that packages slipped through the cracks with a chnage to where we install site-lisp files (or doesn't set the search path or something). Would you mind opening a bug?
<jgomo3>jackhill: Sure, I will, but before: are you sure is not my system which is wrong?
<jackhill>jgomo3: doesn't work for me either. I already had it installed because I used it in the past, but I guess not for some time.
<jackhill>and I appreciate you opening the bug, that way we probably won't forget about it :)
<awb999>any idea, ho I would be able to run vscode (visual studio code) via guix ? It seems not to be available as a package. And if I switch to guix sd, then I would need to have some kind of idea how to run it.
<jgomo3>jackkill: I had to (require 'rec-mode). After that, the rec-mode works fine.
<jackhill>jgomo3: ah I see, I guess I made the same mistake. Well, at least there is pleasure in company. If you want to close the bug, you can send that information to firstname.lastname@example.org . Otherwise, I'm happy to do it since I lead you astray
<efraim>genr8_: agreed, send a mail to guix-devel. I certainly like the idea for unpacking xz tarballs. Doesn't help that IIRC we still default to xz compressed tarballs after applying patches or source snippets
<Frosku>Has anyone got aws cli (v2) working on guix?
<lle-bout`>rekado: hello! :-) what's the URL for downloading patchsets on issues.guix.gnu.org? Since search doesnt seem to work well in logs.guix.gnu.org I can't find your older message and I don't keep IRC logs so.. :-S - Thank you!
***lle-bout` is now known as lle-bout
<raingloom>hmmm, does --keep-failed not work with offloading?
<contrapunctus>I'd like to install Guix, but I have an LVM setup and I'm not familiar with Guix or its DSL...the news file shows an example of defining an LV, and the docs have an example of defining a mount point, but how do I define an LV as a mount point? 🤔
<roptat>civodul, pushed, the redirection should be active after the next berlin reconfiguration
<roptat>it's not like it's actually going to be used, but it looks like a nice project, if it weren't for rust
<roptat>I mean, I understand why some people want to rewrite everything in rust, but the bootstrap chain is prohibitive
<yoctocell>abcdw: Should we have a way to create an XDG MIME .desktop file using the Scheme API?
<lle-bout>roptat: once mrustc or the gcc rust frontend can compile the reference rust compiler then it'll be OK, but what I am more worried about is that this new coreutils is under a permissive license.
<civodul>roptat: yeah, that vision is somewhat interesting technically but the implications (getting rid of copyleft) are worrisome
<lle-bout>Noisytoot: I'm not sure I have modifications, it is likely there's more momentum on the permissive version socially now
<lle-bout>rekado, civodul: What's troublesome with the "Rewrite It In Rust" culture is that it also carries the "Rewrite It Under a Permissive License" side of things most (if not all) of the times
<lle-bout>Basically most people who spend the effort with rewriting in rust arent much aware about Free Software political ideas or vision in any way, they just like Rust and go with the flow
<lle-bout>I have experienced multiple projects where they were under AGPL even, and the original author has got a contract with a company and asked everyone to sign a CLA then re-licensed under Apache2 and everyone signed it without questionning anything, that was quite troubling to me. When asked people said they just did not care they just liked Rust.
<paulj>Good afternoon all! I appear to have introduced an error into my system config, but as yet I haven't been able to put my finger on it. If I load guix repl, then ,use the definition, I get an error: "Wrong number of arguments to #<procedure cons (_ _)" but I don't see which line number has triggered this error. Is there a way to get the repl to give me more information?
<paulj>roptat: I'll do that then, as there isn't any backtrace available. I'll also try cons* instead where there is cons, but I am not sure of any change made recently (since the last successful system reconfigure.
<roptat>Noisytoot, I don't see any from the ci website, but there might be some
<roptat>paulj, if you share your config (on paste.debian.net for instance), I can have a look too
<sneek>ydeb, apteryx says: do you have an idea of how --check should be changed to make it more natural to use? One idea: if the package isn't in the store yet, fetch it as a substitutes or build it once, then proceed to build it a second time to validate the result.
<GNUtoo>Hi, in regular distros when running "pacman-key --populate <keyring-name>", pacman-key looks into /usr/share/pacman/keyrings/ for the name of the keyring. There are several keyring packages (one for Parabola, Archlinux, Archlinux32, Archlinuxarm, Hyperbola, etc). How can I do that in guix? AFAIK pacman-key and each keyrings are supposed to be in separate packages.
<lle-bout>I saw it independently on my mail box, it's in the pipe
<lle-bout>abcdw: will make sure to watch your latest stream as well, I am not expert schemer so I did not understand various things in earlier streams but really like you make those!!
<GNUtoo>lfam: oh ok, that's how it works then, thanks.
<GNUtoo>my case is a bit different but I'll try to make it work in this way nevertheless
<GNUtoo>I'll just depend on all keyrings and it should work
<civodul>roptat: re JLL, i'm not sure what that means! we should ask nixo (Nicolò)
<lle-bout>abcdw: hey! I have a question, I currently use GNOME Evolution and with GNU Guix home probably I'll want to use isync/mbsync but I am concerned with the way the password is provided to isync/mbsync, what do you think about that? I would maybe some pinentry prompt every time that password needs to be used, also user services for regular synchronization? Does isync/mbsync support live sync?
<jgomo3>I'm using Keybase file storage and git repos for my secrets, including master password. That way I can access them from any of my devices using Keybase :D
<roptat>is there a reason why my I have two directories in $GUIX_LOCPATH? (2.29 and 2.31)
<roptat>oh, (gnu system locale) lists glibc and glibc-2.29
<roptat>"to ease transition", except we never updated that definition when we transitioned to 2.31 apparently
<jgomo3> "libc suffixes each entry of GUIX_LOCPATH with /X.Y, where X.Y is the libc version—e.g., 2.22. This means that, should your Guix profile contain a mixture of programs linked against different libc version, each libc version will only try to load locale data in the right format. " From the manual 2.6.1 Locales
<jgomo3>After creating a Profile, which is done simply by `guix package --profile=<the-path> ...`: What is the proper way to remove a Profile? Just by removing the directory?
<roptat>jgomo3, yes, that I knew, but I didn't understand why there were two libc versions, now I do, but I think it's a mistake :)
<lfam>roptat: You can remove the old one after all the profiles have been updated to the new libc
<lfam>Like, each user's profile, and the system profile
<roptat>jgomo3, yes, the profile is just a symlink to the store, and a gc root. If you remove the path, the gc root becomes invalid and next time you run gc, guix will remove the root automatically
<PotentialUser-32>Friends, I am a newcomer and know very little about computers. I have had Guix on my computer for several months, but without a lot of personal files, the computer memory (500 GB) is almost full! However, I worked with Debian for more than a year and I did not have this problem. This seems to be because of Guix updates, should I delete something af
<jgomo3>PotentialUser-32: Maybe you could run the Garbage collector to free space: `guix gc`
<roptat>PotentialUser-32, usually I run the gc with a specified amount, to prevent it from collecting recent stuff that I might still need, like "guix gc -F50G" would limit it to collect just enough to have 50GB free on the disk
<roptat>every time you update guix, you can get a new version of files. Even though there is deduplication, it can take a lot of space on disk for things you don't use anymore (it's kept around as cache or as part of previous generations that are still available)
<jgomo3>PotentialUser-32: Also, I can imagine you having old generations or profiles pointing to software you don't use.
<abralek>PotentialUser-32: you can use --delete-generations where -d [duration]
<jgomo3>ProtentialUser-32: Until you remove those references, the GC will not remove those packages.
<lfam>For containers, --expose (resp. --share) exposes the file system source from the host system as the read-only (resp. writable) file system target within the container. If target is not specified, source is used as the target mount point in the container.
<lfam>Maybe it got worse for 5.2.0, I don't know. I was hoping it would speed up but it didn't
<apteryx>right! For the transparent (user) emulation though I think the builds happen in the normal Guix build container, without any 9p fancies. The only magic is the binfmt-misc registrations that tell the kernel that detect when, say, ARM binaries are executed, and launch them through QEMU, IIUC.
<lfam>A lot of ARM binaries being launched over and over again
<apteryx>It's surprisingly simple; it even works for things like Docker now. E.g., if you have binfmt entries for armhf, you can do: docker run --rm arm32v7/alpine uname -a --> Linux e5f71906ae1d 5.11.11-gnu #1 SMP 1 armv7l Linux
<jackhill>cool. My question is, should (require 'rec-mode) be nessisary.
<leoprikler>there seem to be no autoloads provided, so yeah, that's a bug in emacs-recutils, not in the guix packaging of it
<roptat>oh, I wanted to fix the locale issues people are experiencing when testing the website by providing the locales in the manifest, but I can't use computed-files in a manifest?
<efraim>lle-bout: if it's still relevant for mbsync I use Tunnel instead of PassCmd in my .mbsyncrc : Tunnel "ssh -o Compression=yes -q my-mailserver 'MAIL=maildir:~/Maildir exec /usr/lib/dovecot/imap'"
<djeis[m]>So I'm trying to write a package for a program that uses cmake and links against a particular version of LLVM and clang, but I keep getting "ld: cannot find -lgcc_s" when I try to build it. Am I missing something obvious? I've been tinkering with the package definition for about a day now but I admit I'm still a beginner at this.
<roptat>djeis[m], that doesn't look like a stupid mistake on your side at least :)
<djeis[m]>Yeah it's driving me up the wall. I'm mostly trying to avoid having to build my own copy of LLVM 8 and clang on this machine, and I figured it'd be a good excuse to learn guix packaging better.
<roptat>so, I'd check what cmake is trying to do, and if it tries to override LIBRARY_PATH or similar
<roptat>I suppose you didn't override the "gcc" input with llvm, right?
<roptat>so you actually have gcc (provided implicitely) in the build environment