IRC channel logs


back to list of logs

***catonano_ is now known as catonano
<bdju>I am about to install nim and I see the version packaged is out of date. it's on 1.0 now and I see 0.17.2 in the search results
<bdju>oh that makes it 2 years out of date...
<bdju>and waybar still fails to build
<marusich>bdju, sounds like a good opportunity to update it! Did you check all the branches, master, core-updates, and staging? Perhaps someone has already updated it there?
<artu>trying out guixsd, and installed icecat by "sudo guix package -i icecat". but neither it created a menu item in mate DE, nor could I run it on the terminal through its shortcut
<artu>am I missing something?
<reepca>artu: are you logged in as root in the DE and in the terminal?
<reepca>"sudo guix package ..." will install only for root. "guix package ..." will install it only for the current user.
<artu>no. logged in as 'artu', but used sudo to install.
<artu>ok. figured it now.
<reepca>I believe if you look in /root/.guix-profile/bin you will find icecat there.
<reepca>artu: 👍
<artu>awesome. thank you guys
<reepca>if you want it to be available system-wide, add it to the PACKAGES field of the operating-system record in your /etc/config.scm
<artu>that would be great.
<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 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
<bdju>maybe I'll come around someday
<artu>actually my laptop have 2 wireless adapters and guix installer crashed when I tried to use one of the wifi adapters. maybe there's already a bug report for that
<marusich>Well, when you feel ready, I know you'll find people willing to help.
<artu>how can i submit the bug in guix?
<marusich>The first step would be to check if a similar bug report has been created. You can view existin bugs in a web browser via:
<marusich>If nothing likely shows up, you should send a bug report to
<marusich>I also find it useful to search the following email list archives, since sometimes people talk about a problem without reporting a bug:
<bdju>for waybar failing to build I already sent in one. #37533. for nim being updated, not sure if that can be reported somewhere
<artu>ok. thanks for this information
<marusich>You're welcome!
<kabo>hi! how do I install please?
<kabo>tried installing gcc-toolchain, didn't work
<kabo>is there a way to search for packages that provide a file?
<kabo>I can find the docs, libsdtc++-doc...
<nckx>kabo: is part of gcc:lib.
<kabo>guix package -i gcc:lib
<nckx>You won't be able to install that from the command line, though.
<kabo>error unknown package
<nckx>It's hidden.
<nckx>Yes, hence my message.
<kabo>ah, of course
<kabo>so... is there a secret command to install hidden packages?
<nckx>kabo: What are you trying to do/build?
<kabo>swapped out gcc for gcc-toolchain
<kabo>but doesn't seem to be that easy
<nckx>kabo: Ooh, that's a nice simple way to run binary FF.
<kabo>yes, if it had worked :)
<nckx>kabo: Well, the ‘secret command’ (it's not) to install hidden (well, any) package from an expression is guix package -e '(@ (gnu packages gcc) gcc)'.
<nckx>Problem is that only installs :out.
<nckx>I'm trying to write a gexp that installs :lib but hm.
<nckx>Works: guix environment --ad-hoc -e '(list (@ (gnu packages gcc) gcc) "lib")'
<nckx>Fails: guix package -e '(list (@ (gnu packages gcc) gcc) "lib")'
<reepca>kabo: if there's a good chance it's already used indirectly by something in guix, you could just 'find /gnu/store -name ""'
<nckx>reepca: It's in gcc:lib.
<reepca>nckx: aye, just for future reference
<nckx>But it's so dirty.
<marusich>One way you could get that "hidden" package is to make a profile which specifies it, and then do: "guix package -p /tmp/profile -m ~/profile-gcc.scm"
<marusich>You could add it to your profile manifest, if you have one already. The point is that you would need to declare it like this:
<marusich>(packages->manifest (list (list gcc "lib")))
<marusich>With a '(use-modules (gnu packages) (gnu packages gcc))' at the top of course.
<reepca>indeed it is, but it's the best we've got so far. A full list of files provided by every package in guix is the sort of thing you'd need a build farm to handle.
<nckx>kabo: What I'd do is create a manifest (it's how I install all my packages), then specify gcc:lib there.
<marusich>nckx, if you use specifications->manifest, that won't work because gcc is hidden.
<kabo>hmm, after running that I still can't find in .guix-profile/lib
<marusich>If you use packages->manifest, it will work, although whether that is a bug or not is up for questioning :)
<nckx>marusich: I think I'm lagging like crazy. Did you answer before I did? I think so.
<marusich>I think I did.
<marusich>nckx, it's present at /tmp/profile/lib/
<nckx>marusich: Okido. Sounds sane, by the way.
<marusich>Does it need to end in .6?
<marusich>Oh, that's also present at /tmp/profile/lib/
<nckx>I'm just annoyed that you time-travelled to steal my clever manifest idea.
<nckx>marusich: Yes.
<kabo>my /tmp is empty
<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>There was some discussion about this on the email list recently; you can search the archives and find the message:
<nckx>kabo: What did ‘guix package -p …’ say?
<nckx>It works fine here, in /tmp.
<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.
<kabo>ah, sorry, missed that part
<kabo>reading docs on how to write manifests...
<nckx>marusich: See the ‘oh right that works too’ interpreter hack at
<nckx>Unless FF has grown random sub-binaries.
<marusich>It has some you'll need to patch; I've done it before.
<nckx>kabo: echo '(use-modules (gnu packages) (gnu packages gcc)) (packages->manifest (list (list gcc "lib")))' > manifest.scm if you just want to get going.
<marusich>At least, I think it does. I've also done this for other software that was not compiled for a Guix system originally, as a quick hack.
<nckx>I've done it on NixOS, not on Guix since, packaging is too easy.
<marusich>gotta run, see you later!
<nckx>I'm going to stop talking now; time-travelling really isn't as fun as it sounds; good luck kabo!
<kabo>hmm, that didn't work either
<kabo>edited the LB_LIBRARY_PATH=/tmp/profile/lib
<kabo>Exic failed with error: No such file or directory
<kabo>if I run firefox-bin instead of firefox I get Couldn't load XPCOM.
<kabo>I like the idea of manifest files
<kabo>sometimes I install a package to see if it fixes an issue I'm having, and then uninstall it if that wasn't the right package
<kabo>would you add it to the manifest and then remove it, or would you run guix install and if it worked add it to the manifest?
<kabo>how do I install packages found in ?
<kabo>guix build firefox.scm ?
<kabo>does guix support appimages?
<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>kabo: I doubt it.
<nckx>We're not big on binary blobs.
<kabo>ok, so I need to fork jsoo1's repo, edit firefox.scm, push that and then I do what you described above?
<nckx>kabo: If jsoo1's repository doesn't provide what you want, yes.
<kabo>it's running firefox 60, so no, it doesn't
<kabo>might as well run icecat then
<nckx>kabo: What's new in Firefox>60land?
<kabo>performance, fingerprinting resistance, tracking protection, FIDO, dark mode, WebExtensions run in their own process, better container experience, etc
***dekenevs is now known as mitescugd
<kabo>one of the things that appeal to me is that guix seem to be running fresh stuff.
<kabo>new stuff is available in guix sooner then in debian
<nckx>Heh. I never considered ‘freshness’ our strong point but I guess we can compete with Debian on that point.
<brendyyyyn>I went and updated and now I can't boot at all. It drops in to grub rescue and says symbol grub_file_filters cannot be found
<nckx>brendyyyyn: Is this on EFI? This sounds like you're booting an older GRUB core image that doesn't match the files (loadable modules) actually on disc.
<nckx>Make sure you're booting /boot/efi/EFI/Guix/grubx64.efi.
<nckx>Make sure there's no long-forgotten old EFI partition or executable somewhere that's being booted by mistake.
<coco>i'm surprised not to find the 'clear' command in guix
<bdju>does ctrl-l work?
<nckx>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.
<nckx>coco: Isn't it provided by ncurses?
<coco>bdju: oh, yes, it does
<coco>nckx: i don't know
<nckx>bdju saves minutes of coco's time for the rest of their life.
<nckx>coco: I just checked, it still is. (ncurses also provides the ever-handy reset, which I do use.)
<nckx>s/bricewge/brendyyyyn/, who left.
<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.
<janneke>ah no, that's okay
<janneke>my reason for asking is more along the lines that we started using git commits for github packages instead of tarballs, because we cannot count on them being reproducible
<janneke>i was wondering if it maybe fixes something with --with-source or so
<nckx>janneke: Not AFAIK; my beef is completely semantic, not practical.
<janneke>also, i like consistency, at least once we figured out what's the best way to do things, until then experimenting is fine too :)
<janneke>okay, thanks
<nckx>I see a lot of new contributors emulate it, that's when I started slowly getting rid of 'em.
<janneke>some people put synopsis or home-page as one of the first entries in (package; which makes sense
<janneke>also, using (string-append name ) does not work when inheriting a package
<coco>for users, 'guix package -i' install packages according to the guix version obtained with 'guix pull'. what about globally-visible packages ( what version of guix is relevant for those?
<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@'"
<nckx>…oh! The runit one! 🙂 Thank you, foxmean.
<janneke>foxmean: good, have a look at etc/, 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.
<nckx>Both are fine!
<nckx>Don't worry about it yet.
<foxmean>nckx: thanks, and I will come back to ask you some extra questions. Thanks so much. Now, I've to go out. :D
<nckx>foxmean: o/
<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?
<nckx>coco: Do they point to the same thing?
<coco>nckx: no, they point to different places in /gnu/store/
<nckx>coco: Odd. When I do that:
<nckx>lrwxrwxrwx 1 root root 50 May 19 01:51 system-98-link -> /gnu/store/f877i86s2dkkdjr4dnvlz1nqwadvbvpa-system/
<nckx>lrwxrwxrwx 1 root root 50 May 19 02:58 system-99-link -> /gnu/store/f877i86s2dkkdjr4dnvlz1nqwadvbvpa-system/
<nckx>(Yes, random ancient example and I should clean house.)
<coco>for me:
<coco>lrwxrwxrwx 1 root root 50 Oct 5 13:31 system-5-link -> /gnu/store/g8wgbwng9mzamy2nawl7q5x6isjv04rl-system
<coco>lrwxrwxrwx 1 root root 50 Oct 5 13:44 system-6-link -> /gnu/store/p5813npfq057pk35rigjr80h0lscc2r9-system
<nckx>You could use diffoscope to compare those two paths if you're really curious.
<desmes>nckx: I've installed both and I can't still use "strings" though
<coco>it's odd, it also downgrades the linux-libre kernel...
<nckx>This sounds (I can only guess) like ‘which guix’ confusion, maybe because of sudo?
<nckx>desmes: Well, `guix build binutils`/bin/strings is real and works, that's all I can tell you.
<coco>i did it both times as root
<nckx>Sure, but how.
<nckx>If one time your user's Guix was used and another time root's, that could lead to downgrades. I don't see how else that can happen. Guix is deterministic.
*nckx must go, some people need me.
<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
<coco>nckx: have a good one
<desmes>nckx: You are right, I can use it if I write the whole directory and then a file name... I wonder why it's not in my path though
<desmes>nckx: Damn, I used "sudo guix package"...
<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?
<civodul>mbakke, nckx (+ apteryx): we have some good news i'm about to push!
<civodul> \o/
<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.)
<bandali>hmm, i’m not sure about that
<bandali>perhaps one of the prolific guixers here could help answer that
<bandali>i’m mostly a mere noob myself
<coco>because in fact, i did run 'guix system reconfigure' before the first time i ran 'guix pull', and that's the only thing i can imagine that i'm doing / did wrong
<brendyyyn>nckx; the only thing in /boot is a grub folder
<sneek>brendyyyn, you have 4 messages.
<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.
<mbakke>civodul: yay :-)
*mbakke goes afk for a while
<nckx>Hullo everybody.
<nckx>brendyyyn: So you're not using UEFI?
<brendyyyn>i dont think so no
<brendyyyn>ive managed to chroot in from the install image
<nckx>Then perhaps you're booting from the wrong MBR (boot drive) if that's possible, or it really is a GRUB 2.04 bug…
<brendyyyn>im not sure rolling back the generation would change anything
<nckx>Sorry about the message spam, I told sneek to forget some but she lied…
<nckx>brendyyyn: I'm almost certain it wouldn't, unless it happens to reinstall GRUB in a way that fixes this.
<nckx>But that would be non-deterministic so all bets are off.
<nckx>TL;DR: ‘try stuff’, sorry.
<brendyyyn> all i did was change the elogind service in my config im not sure that would kill everything
<nckx>No, that won't break GRUB.
<lprndn>Hello guix
<lprndn>is anyone acquainted with gnome-settings-daemon? (gsettings? is it related?)
<CcxWrk>Is tcb passwd format supported by Guix?
<nckx>CcxWrk: Not if it still requires patching everything to support it.
<nckx>Now there's a blast from the past.
<roptat>hi guix!
<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
<roptat>in the end, I was able to fix all this by using a switch in the middle, that's weird :/
<janneke>one way or another, roptat stays connected ;-/
<roptat>I use a bouncer
<nckx>roptat: Have you tried different cables?
<roptat>all with the same result
<roptat>cat6, cat5e, with 1 or 4 pairs inside
<roptat>the overdrive booted successfully on the guix system!
<nckx>roptat: Awesome! We can use the help.
<grumbel>What's the equivalent to 'apt-get source' in Guix?
<grumbel>i.e. quick way to get access to a packages source code or a filename
<nckx>grumbel: guix build --source
<nckx>grumbel: ‘Filename’?
<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.
<Minall>Hello guix!
<bdju>next browser seems to just spit out errors when launched now
<emacsomancer>bdju: yeah, I noticed this. try running via the full path; it should work
<emacsomancer>e.g. ~/.guix-profile/bin/next