<marusich>artu, just in case it wasn't clear, you do not need to install packages as root. In Guix, every user has their own independent default profile, which is manipulated by running "guix package -i foo". You can even install different packages to different profiles with "guix package -p /some/other/profile -i icecat@some-other-version"
<artu>so the profile can be any file I specify on the filesystem?
<marusich>Yes, but if you don't have a specific need to create a separate profile, it makes sense to just use the default profile for your user, which is located at ~/.guix-profile
<bdju>marusich: I'm not too good with guix packages. did not check any of that, but I did email bug-guix about waybar a few days ago
<artu>got it. seems like need to read your manual more :)
<marusich>bdju, for what it's worth, the Guix community is very friendly to newcomers, and if you try to update the package and cannot figure something out, I'm sure you can get help either here or on the firstname.lastname@example.org email list. The first step is to try it out!
<artu>i liked guile and feeling like contributing to the code
<bdju>marusich: been here almost 2 years now, it's all just a big pain for me. I don't mind reporting some bugs and adding to the wishlist but hacking on guile is not my idea of a good time
<nckx>It should just work if we then adjust LD_L_P (and it's arguably cleaner).
<marusich>FWIW, the right thing to do would not be to use environment variables to tell Firefox where its libraries live at runtime, but rather to compile it right from the start. But since it isn't packaged in Guix, I guess that's a non-starter.
<marusich>If you're going to go the "patch the binary" route, you will probably also need to invoke patchelf to update the ld interpreter path in not only the firefox executable but any other ELF files it embeds that you need.
<nckx>kabo: To use a channel you can create a ~/.config/guix/channels.scm file with (cons* (channel (name 'foo) (url "https://foo") (brach "foo")) %default-channels) and guix pull. Then you can just ‘guix install <new package>’.
<nckx>sirmacik: Guix's cryptsetup now supports reading & creating LUKS2 containers. It still defaults to creating LUKS1 because the rest of the distribution doesn't.
<coco>is there a difference between running 'guix pull' as root and running 'sudo guix pull' as a non-root user?
<janneke>foxmean: have you worked with git before?
<janneke>nckx: what's the insight that we are now hard-coding package urls rather than using NAME, any info on when and where we want to do that?
<nckx>janneke: Er, I got fed up the nth time that unnecessary parametrization made me do an extra visit-edit-eval loop, nothing more. Any advantages to using NAME?
<nckx>I mean, maybe there are and I just fail to see them (I've asked before). It seems very ‘I can so I will’ to me, and then it causes random tiny maintainership itches just often enough to be really annoying.
*janneke gotta learn about visit-edit-eval loop...
<janneke>nckx: just curious, i support what you say: it can be parameterized...but is it wise, i really dunno
<janneke>the ascii is the same, but are the semantics identical?
<nckx>I do agree (if it's the reason you're asking) that doing it a separate commit makes it seem like an issue that it totally isn't. I just don't like smuggling in changes that aren't related, comments & whitespace excepted.
<foxmean>janneke: Not so call 'work with git like a professional'. But I was play it: commit, git pull, occasionally (something like git pull with AUR, create some basic html site in GitHub page in the far part).
<nckx>janneke: It makes perfect sense, so does putting it at the end, the tie-breaker is consistency with the other 10k packages.
<nckx>foxmean: Can you ‘git send-email’? That's the easiest way to submit patches to guix-patches@ but you have to configure git, once, to use your SMTP account.
<janneke>nckx: foxmean already created a fine bug report, and now may want to add a real patch to it
<janneke>foxmean: if you want, first clone guix' git archive, have you done that yet?
<foxmean>janneke: Yes, I've done it. Now I've no idea what '@localstatedir@' is?
<foxmean>Could you please help me rewrite the line "exec /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild" to "configurable`@localstatedir@'"
<janneke>foxmean: good, have a look at etc/guix-daemon.service.in, that file is the input that is used to produce ./guix-daemon.service
<foxmean>nckx: This is the first time I've seen 'git send-email'. Is it need to be learn or should be learn for contribution?
<nckx>foxmean: It's not required. You can also use ‘git commit’ to create, well, a commit, and then ‘git format-patch -1’ to create a patch file that you can manually attach to an e-mail in your favourite client.
<nckx>However, ‘git send-email’ is (IMO) more efficient/convenient/pleasant when you regularly submit patches.
<desmes>Hey guix! Which package should I install so I have the "strings" bash command? I can seem to find it with guix package -s
<nckx>desmes: binutils (also included in gcc-toolchain).
<coco>i'm confused. when i run 'guix system reconfigure config.scm' two times in a row, without doing anything in between, i end up with two new profiles, pointed to by two symlinks /var/guix/profiles/system-x-link and /var/guix/profiles/system-y-link. since i didn't change the config.scm and did no guix pull, shouldn't i end up with two identical system profiles?
<coco>i see your reasoning. maybe i'm doing something stupid, but i don't see how. first, i did 'root@elephant /home/coco# guix system reconfigure /etc/config/config.scm', then i did 'root@elephant /home/coco# guix system reconfigure /etc/config/config.scm'. i had a second shell open to check the system symlinks
<desmes>I'm sorry for my stupidity. Does anyone know what happens if I install a package as sudo though? As far as I understand, system's packages are only defined by what is declared in the scheme config file. And a user's packages are only defined by their profile ("guix package -i..."). If you use "sudo guix package -i...", is that package installed as the whole system (therefore, the next time you run "sudo guix system reconfigure" it won't
<desmes>be accessible), or is it installed under the "root" profile?
<janneke>lovely \o/, congrats and thanks mbakke, nckx!
<coco>'guix system reconfigure' keeps downgrading my system, and i have no idea why. 'guix --version' now gives me 'guix (GNU Guix) 0.16.0-13.b8b1e4d', even though i started the barebone installation with 1.0.1. what is going on? how can i get the system up-to-date? is there anything more to do than 'guix pull' and 'guix system reconfigure'?
<coco>what do i need to do to bring my system up-to-date?
<bandali>`guix pull` pulls latest changes from upstream
<bandali>you could then either reconfigure or do something else
<coco>does running 'guix system reconfigure' the first time before ever running 'guix pull' do something that i cannot recover from later?
<coco>i keep running 'guix pull' and 'guix system reconfigure', and the only effect is that it's downgrading and downgrading (which i see from the linux kernel version, the guix version etc.)
<sneek>brendyyyn, nckx says: bricewge: I think we switched from /EFI/GuixSD to /EFI/Guix once. That was a while ago, though. You can delete the old one or back it up if you're nervous.
<sneek>brendyyyn, nckx says: I think we switched from /EFI/GuixSD to /EFI/Guix once. That was a while ago, though. You can delete the old one or back it up if you're nervous.
<sneek>brendyyyn, nckx says: It's also possible that this is a real bug somewhere in GRUB 2.04, and that downgrading to 2.02 would fix it.
<sneek>brendyyyn, nckx says: That's unlikely though: those proclaiming on-line that ‘it's a bug because downgrading to 2.02 fixed it!’ probably have, you guessed it, a stale forgotten 2.02 GRUB core image somewhere.
<roptat>I've got my internet back and trying to fix the overdrive
<roptat>I'm in a new house, and the internet is being weird. we have ethernet in every room, but where I have my computer it doesn't work well with all of my machines
<roptat>when I put a cable in my Haiku system, it works perfectly well
<roptat>with my guix system, it doesn't work when using the port on the motherboard (ip says no-carrier), and somewhat works on a separate pci card (it says there's a carrier but I don't receive a dhcp lease all the times, I have to unplug/plug the cable a few times for it to work, then it work perfectly well)
<roptat>and with the overdrive on the OpenSuse system, I had the same issue with no-carrie
<grumbel>filename of the tarball I meant, build --source does the trick
<grumbel>What's the reason for naming inputs twice, e.g. ("libsoup" ,libsoup) and is there any convention to it, as I sometimes see ("gtk2" ,gtk+-2) where the variable name and string mismatch
<nckx>grumbel: It's really an a(ssociative )list. The convention is to use the package name, although the key (string) part can be more generic (e.g. ("foo" ,foo-1.0)) or otherwise give a hint as to what the package actually provides. That's rare though.
<nckx>("gtk2" ,gtk+-2) is just sloppy naming, perhaps for historical reasons, but there's no good reason for the mismatch.
<nckx>Techinacally, the key string doesn't matter, it's only rarely used in build scripts as (assoc-ref inputs "the-name"). It can be anything and work. It's just for humans. Some day, it will vanish and we'll just use regular lists and live in harmony or something 🙂
<nckx>We'll also spell technically correctly. It'll be glorious.