IRC channel logs


back to list of logs

<benjamin1>is there a way to get a debug repl for a failing build
<benjamin1>ah, figured it out
<benjamin1>nvm spoke too soon
<benjamin1>I tried running 'package-derivation' in a guix repl, but the debugger it dropped me into was for the client, not the build daemon
<mbkamble>Can anyone suggest how services launched from my home-environment (eg emacs daemon) see the env variables (specifically PATH)  setup from ~/.bash_profile rather than just that of /etc/profile? I have packages in ~/.guix-extra-packages that I need to be accesible in emacs
<lilyp>mbkamble: wrap them in a shell script that sources the relevant extra packages?
<mbkamble>how I ensure that it gets source by shepherd? This is the pstree hierarchy of emacs: hepherd(1)───shepherd(2245)───.emacs-28.1-rea(2246)
<lilyp>have shepherd launch a shell script or alternatively, since it's guile code, have shepherd setup the environment variables
<mbkamble>understood. I think I have the skills to write the shell script and launch all my daemons through it (emacs, gpg-agent). I don't kow guile enough to achieve the env var setup for shepherd
<nckx>Oops, sorry for the spam.
<mitchell>When i cross compile for arm-linux-gnueabihf and run `file` on the output it tells me it's compiled for "GNU/Linux 2.6.32" How can i build it for other versions like 3.2.0?
<sneek>mitchell, you have 1 message!
<sneek>mitchell, maximed says: (untested)
<mitchell>wait it is not the problem. It is only guile that has a problem starting
<mitchell>guile -v and -h work. but it crashes when launched normally
<nckx>mitchell: You'd have to modify glibc but why would you ever want to do that?
<nckx>mitchell: Do you know what that number means? If not, don't touch it. I don't see the connection to Guile so assume it's unrelated.
<nckx>Sorry, just a bit worried you'd brick your system to make number go up :)
<mitchell>I do not know what that number means
<mitchell>However i've narrowed the problem down to my specific package. When i say "guile" i mean a c program i've written which links against the guile library
<mitchell>when i pack guile, it works. when i pack my application it segfaults on cross compilation but works natively
<mitchell>I'm sure the problem is in the way i've defined my package and not with guix or guile
*nckx 's not that sure, but if you are...
<nckx>Since you mentioned glibc (deliberately or not): you're not mixing host & Guix libraries in one process, right? That seldom works.
<nckx>I must go, however, my 2h of sleep need me.
<mitchell>No I was simply taking a stab at the dark and ran `file` on a binary that worked and on my program. The only difference was the glibc version (which i guess is what that number is)
<mitchell>but i made another pack with some other stuff, including guile, and it all worked fine
<nckx>It's the minimum Linux kernel version that the glibc the binary links against will run on. But even that is a bit of a lie in Guix, since the only '2.6' we support is actually heavily patched IIRC. Long story short it really isn't something you should worry about.
<nckx>It's nothing to do with library versions.
<mitchell>any ideas on what i should look at?
<nckx>What do you mean by pack, and where are you running this pack?
<nckx>I doubt I'm going to generate ideas at this hour.
<nckx>I'd ask you to share your complete package if I were sticking around, so if nobody shows up I suggest asking the help-guix mailing list and including more details & code.
*nckx nodding off; good night.
<mitchell> Here is my approximate package definition. This is a work thing and I cant share the sources with the outside world but i am not doing anything except calling scm_boot_guile which should drop me into a repl. I am cross compiling to a xilinx zynq-7000 which is a cortex-A9 armv7. I call the following `guix pack --target=arm-linux-gnueabihf my-guile guile htop tree`. I copy the resulting tarball to the
<mitchell>device, unpack it, and source the profile. All the programs work as expected except my-guile which seg faults when not run with --help or --version.
<mitchell>strace shows it trying to load a bunch of guile site files (and succeeding?) until it crashes
<mitchell>the guile package itself has a lot of propogated inputs. Perhaps i should inherit those to my package as well
<benjamin1> <- running into a build failure with nss-certs that seems to be related to it picking up a locale that doesn't support UTF-8, but I'm not sure where to go from here for debugging
<benjamin1>this is from a guix installation on top of void, and I wrote a runit script for the daemon myself
<benjamin1>wondering whether the 'LANG' environment variable for the guix-daemon itself matters actually
<benjamin1>oh shit that was it
<benjamin1>also cursed
<benjamin1>it seems like that kinda breaks reproducibility, right?
<benjamin1>if the locale of the host running the daemon affects the result
<benjamin1>I'm probably missing something
*yewscion is back (gone for 06:57.44)
***piyo` is now known as piyo
<retropikzel>I'm trying to make package out of stklos. If I download the source and do ./configure && make it works. Put when building as package ./configure fails to recognise the OS and the build fails on compilation. Can I somehow make ./configure find the info even when compiling as package?
<lilyp>"configure fails to recognize the OS" sounds rather cursed
<lilyp>in any case, utils/shlib-options has the magic
<maximed>benjamin1: FWIW, guix could detect that the UTF-8 hasn't been set up and bail out?
<maximed>And there are some plans for making Guile support files with arbitrary file name encoding (independent of locale) which would make things more error-prone
<maximed>Though as it is currently, it also seems a reproducibility problem to me.
<retropikzel>lilyp, I can find multiple utils files but not shlib-options
<jmes>Maybe a dumb question but where are .so files installed on guix? I need to do stuff with CFFI in common lisp, but it's not found after installing with guix install.
<unmatched-paren>jmes: they're in /gnu/store/...-some-package-0.2.8-.../lib
<jmes>unmatched-paren: right, so what is the guix way to have that in my PATH like it would be in a more traditional /usr/lib directory?
<unmatched-paren>if you have them in your profile, they're symlinked to ~/.guix-profile/lib/
<jmes>oh, that's what I need! Thanks
<unmatched-paren>so i guess you'll need to point CL to that directory :)
<jmes>Yes, perfect :)
<unmatched-paren>Usually we use pkg-config files to figure out where libraries are in C builds
<jmes>I'm still wrapping my head around guix as a noob
<unmatched-paren>Everything you have in your profile gets symlinked into ~/.guix-profile
<unmatched-paren>unless you're using guix home, which uses ~/.guix-home/profile
<jmes>Yeah I think I knew that at one point but I just got back on guix after a hiatus
<unmatched-paren>so if you install "hello", you'll have a bin/hello in your ~/.guix-profile
<jmes>Perfect, I've been learned!
<lilyp>retropikzel: it should be in the source tho...
<civodul>mbakke: yay for all the core-updates stuff!
<bjc>any committers around who can look at 55081? it's a tiny thing that allows me to use geiser with guix over tramp, and it's been sitting around for months
*raghavgururajan updated Gajim
<unmatched-paren>Could someone who's interested take a look at 55903? "[PATCHSET] Adding aerc"
<mbakke>civodul: indeed! Feels good to be hacking on Guix again after a rough year :-)
<efraim>not so happy with openntpd, I always need to restart it after booting up and then my clock jumps forward about 3 minutes
<dhruvin>I am packaging guix for alpine. I got all (guile, and native) dependencies packaged already. I am able to build guix-daemon successfully too. I have a question and an issue I need help for.
<dhruvin>The Makefile requires bash (due to ((line++)) and maybe some other bash specific stuff) and coreutils (cur --delimiter=":" and maybe some other stuff)
<dhruvin>Is this intended?
<dhruvin>I worked around this problem using make SHELL=/bin/bash .. (and having binaries from coreutils available at build time)
<efraim>I assume autotools assumes bash. So I'd guess it's not intentional on our part.
<dhruvin>About the issue: ice-9/eval.scm:293:34: Throw to key `decoding-error' with args `("scm_from_stringn" "input locale conversion error" 84 #vu8(54 130 141 16 32))'
<dhruvin>musl's libintl is too different from gnu's IIUC
<dhruvin>this prevents guile from opening a port with encoding other that utf-8
<dhruvin>Similar problem was occured with boostrap guile and I saw a patch named guile-default-utf8.patch
<efraim>Ooops on the path: /gnu/store/b6v0wp13h2mkq4533ir7l5ddflj9pxhb-openssl-3.0.4/share/openssl-1.1.1l/
<dhruvin>When I try to compile guix, the aforementioned error arises at "[ 14%] LOAD gnu/ci.scm" while trying to load 'gnu/system/install.scm'
<dhruvin>Is there any way to fix it?
<mitchell>why are cross compiled packs so much larger than native ones? When i run `guix pack htop tree coreutils` the resulting tarball is 28M. When I run `guix pack --target=arm-linux-gnueabihf htop tree coreutils` it is 63M.
<lilyp>probably some cross-compilation artifacts are kept in there, plus cross-compilation may not result in optimal codegen?
<maximed>mitchell: Is this only for the pack itself, or for the cross-compiled software itself?
<maximed>You could do "guix build htop tree coreutils --target=..." and then run the store items through "guix size"
<lilyp>ahh, yes, the toolchain is also included in `guix pack', so you'd have to go with the size reported by guix build instead
<maximed>I assume that including the toolchain is an accident, not the intended functionality?
<mitchell>interestingly the arm htop is smaller by 100k
<mitchell>so it must be the toolchain
<mitchell>that makes sense
<mitchell>as reported by du -sh $(guix build...)
<lilyp>maximed: I think `guix pack' means `guix pack everything'
<lilyp>so, who can explain to me how (synopsis ...) ends up in the po files?
<maximed>mitchell: du is not a good check, because it (presumably) does not include the references (≃ runtime dependencies, but not exactly)
<maximed>(guix size takes care of that)
<mitchell>Its true, but guix size doesn't take the --target option
<mitchell>idk how to make it look at both
<maximed>mitchell: You can do "guix size /gnu/store/...-htop-VERSION"
<maximed>though a --target would be nice too
<mitchell>ok guix size $(guix build) does the trick
<maximed>lilyp: mitchell wrote "guix pack ... htop tree coreutils", so 'everything' doesn't seem to include the gcc toolchain here
<maximed>(except for gcc:lib maybe)
<mitchell>guix size includes two gcc's for the cross compiled one
<mitchell>gcc-cross and gcc-10
<maximed>po/guix/Makevars: --keyword=synopsis \
<maximed>po/packages/Makevars: --keyword=synopsis --keyword=description
<maximed>maybe that?
<lilyp>ahh, was looking at the wrong makevars
<mitchell>Actually it packs everything twice?
<mitchell>two bash-static, two ncurses
<mitchell>i'm looking at just `guix size $(guix build htop)`
<mitchell>is it doing some weird grafting?
<lilyp>as I said, it includes native-inputs too
<mitchell>That seems wrong
<maximed>Possibly a package accidentally records a reference to the native-inputs?
<maximed>e.g. both a native and cross ncurses
<maximed>You can use "file" on the shared libraries of both ncurses to see the architecture IIRC
<maximed>(& check if this indeed the issue)
<mitchell>indeed one is for x86 and the other for arm
<mitchell>actually the x86 one is the same in both packs
<maximed>mitchell: To figure out in which package things go wrong, you can (IIRC) use "guix graph --type=references /gnu/store/$the-native-ncurses /gnu/store/$the_store_thing_from_guix_cross_build"
<maximed>(not sure about the exact CLI)
<sughosha>Hi guix, I have fixed my mistakes and resent the patches in <> and <>. I hope there are no more mistakes, in case if there are, I am ready to fix :)
<lilyp>I'll have a look at the GNOME extensions once I'm done with my current patch
<mitchell>maximed: In this --references graph the arrows point to things the package is referencing? or things referencing the package. A->B means A references B or vice-versa
<sughosha>lilyp: thanks :)
<nckx>Not to hammer a dead horse, but now Microsoft 'GUIX' is #1 on DDG for 'guix git', and the real Guix is last, with the Microsoft GitHub mirror somewhere in between.
<maximed>mitchell: I don't know the direction. Just give both a try, I guess: "guix graph --type=references --path /gnu/store/this /gnu/store/that"
<mitchell>I put it through dot and ARM ncurses-> x86 ncurses and gcc-cross-arm-linux...-lib which both point to x86-gcc-lib
<nckx>dhruvin: Patches to make the build scripts run on less common distributions are welcome! I don't find either example in the code, though, although there is an --output-delimiter example in a manual translation.
<nckx>maximed: I have a script that tries both directions & prints the working one because I always forget it.
<maximed>mitchell: Try: grep -rF /gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-6.2.20210619 /gnu/store/rlvkgvy9i0g9bz6k73nn2bxpm2941svy-ncurses-6.2.20210619
<maximed>Apparently it ends up in & libncursesw.a and ncursesw6-config somehow
<mitchell>It gives a warm feeling seeing you have the same derivations
<mitchell>A+ on the reproducibility
<maximed>FWIW it just downloaded substitutes from the build farm ...
<nckx>mitchell: Late, but A->B means A refers to B
<nckx>sughosha: Thanks!
<maximed>I mean, having the same derivation doesn't mean much except that we have the --system and a close-enough version of Guix.
<maximed>For reproducibility, you need to do the hash over the output
<maximed>(whereas /gnu/store/... is the hash over the inputs)
<mitchell>I thought the store path was also derived from the contents of the output
<maximed>mitchell: That's the intensional store model described in the nix paper.
<maximed>We use the extensional model from the paper (if I got the terminology correctly)
<maximed>(There's also the fixed-output derivation exception, for downloading source code)
<mitchell>I have much more to learn
<dhruvin>re: patches to build scripts: ack
<nckx>Just don't expect future contributors to those files to test on every obscure distro under the sun. You might have to keep maintaining the Alpine compatibility. Though, these files don't change that much.
<dhruvin>I won't expect. Thanks for the heads up.
<nckx>Making bash/coreutils a dependency (if Alpine supports those) is equally fine.
<dhruvin>nckx: For now, SHELL=/bin/bash with coreutils works. Any ideas/pointers on that `decoding-error` error?
<civodul>weird thing: sometimes ERC stops notifying me in the mode bar about activity on #guix
<civodul>i wonder if i fell asleep on the keyboard and hit some key combination i shouldn't have
<nckx>No, dhruvin, I'm afraid I haven't a clue. I'm not a Guile contributor (hey, look, here's one!) but I'm not sure building it against musl [libintl] is even worth pursuing?
<mitchell>It maybe worth it for embedded systems
<dhruvin>I didn't mean to bug you if you felt that way. Just asked you if you knew, since you seem to know about guix well. I apologize if that ping was unnecessary.
<nckx>I this is about the ', dhruvin,' making me sound annoyed: I wasn't. I type differently (and much worse :-p) on a touchscreen.
<nckx>I literally don't know, nothing more! Civodul might...?
<dhruvin>I misjudged (or misinterpreted). We're alright.
<nckx>(One advantage of these things. Emojoboards.)
<dhruvin>Regarding binding it to musl, I don't know enought about it. I'll see if its uphill struggle from where I am at packaing guix for alpine.
<nckx>mitchell: Right, I meant worth pursuing as part of bringing Guix (which will end up building *everything* it installs against glibc in the store) to Alpine. It could be a very long detour.
<nckx>Basically what dhruvin said in the meantime.
<nckx>The 'native' Guix package is always just a bootstrap Guix that normal users will use exactly once, to pull a Guix-built (and glibc) guix command.
<constfun>Hello all. I'm having trouble adding an extra config file under /etc/libvirt, like so:
<constfun>"(simple-service 'qemu-config etc-service-type
<constfun>                      (list `("libvirt/qemu.conf"
<constfun>                              ,(plain-file "qemu.conf" "nographics_allow_host_audio = 1"))))"
<constfun>I get a "symlink: File exists: "/etc/libvirt" which is self-explanatory enough, but I'm not sure what to do about it. Is that not the right location for qemu.conf?
<maximed>nckx, dhruvin: and maybe to automatically set up the guix daemon
<maximed>constfun: Are you also using libvirt-service-type?
<constfun>maximed: i am, yes
<maximed>constfun: Then you can use the configuration fields of libvirt-service-type
<maximed>Apparently mixing libvirt-service-type and manually putting files in /etc/libvirt/... is not supported.
<maximed>(maybe libvirt-service-type already makes a qemu.conf by itself?)
<constfun>maximed: hmmm, I dont see a way to supply any options for qemu or any extra config files to libvirt-service-type configuration
<nckx>maximed: True.
<maximed>constfun: Such an option could be added I'd assume.
<james[m]>Hello I have just decided distrohop to GuixSD. (Its currently installing).
<james[m]>I've used it before, a while ago. But now revisiting it.
<james[m]>I intend to use Xen on it. So I will be looking into using virt manager with Xen. Inside guix.
<maximed>james[m]: FWIW it has been named Guix System for some years.
<james[m]>maximed: Ah. Yes it is. Sorry my mistake.
<james[m]>Guix System then.
<james[m]>I could have sworn it used to be called that the last time I used it.
<james[m]>Couple years ago.
<maximed>yes, has been renamed
*james[m] uploaded an image: (116KiB) < >
<james[m]>Done. Now let's try it...
<james[m]>First time for few years.
<constfun>maximed: /etc/libvirt is a regular directory though, so I'm not sure why etc-service-type can't add more files there
<maximed>constfun: because (IIUC) /etc/libvirt/qemu.conf already exists?
<maximed>Or maybe it doesn't exist,
<constfun>it does not
<maximed>Is /etc/libvirt a symlink?
<maximed>Looking at (gnu services virtualization), Guix doesn't seem to touch /etc/libvirt/... at all
<maximed>My guess is that etc-service-type created a symlink farm of all the configuration files it knows about, and then tries to point /etc/libvirt (as a symlink) to somewhere in the farm
<james[m]><maximed> "yes, has been renamed" <- Does it usually take a while to boot on the first try?
<james[m]>My computer is a librem 13v2 so it should be good enough.
<constfun>plot thickens, it could be virt-manager perhaps
<maximed>But it already exists as directory.
<nckx>james[m]: It's not fast, but it shouldn't take minutes.
<constfun>maximed: that sounds like a good theory, ill dig in, just wanted to make sure im not doing something stupid
<constfun>thank you!
<nckx>james[m]: Maybe it's waiting for entropy for the SSH host keys? (Guess.)
<nckx>I'd expect that not to be a problem on bare metal though.
<maximed>Is this in a VM?
<james[m]>No. My machine
<james[m]>I've installed it fully. Now I've put in my encryption password.
<maximed>Remember: GRUB doesn't support pre-decryption non-qwerty keyboard layouts yet.
<maximed>So you might need to, during decryption in GRUB, type it as if your keyboard were qwerty.
<nckx>It'll barf a friendly error message if it fails, though.
<nckx>It won't/shouldn't just freeze.
<james[m]>I am using qwerty I think.
<james[m]>The encryption was fine.
<nckx>Ah, but what about second brea^Wdecryption?
*james[m] uploaded an image: (1208KiB) < >
<nckx>That's what I feared.
*james[m] uploaded an image: (61KiB) < >
<nckx>What kind of GPU does this thing have?
<james[m]>Its good enough.
<james[m]>Its a modern PC.
<nckx>That's… not what I meant.
<nckx>It's not struggling to raytrace the Guix logo. ‘Modern’ AMD GPUs are frequently troublesome, for example.
<oriansj>Guix can run just fine on a pentium pro if you are able to be patient
<nckx>You can try booting with ‘nomodeset’ on the end of the kernel command line (the very long line starting with ‘linux’ when you hit ‘e’ on the Guix entry in the GRUB menu).
<james[m]>I think I will just try the install again.
<james[m]>IDK. But its made by purism and its lts libre friendly.
<james[m]>I never had an issue at least getting it to boot. I will try again...
<nckx>Your time is yours to waste but I'd advise you try my suggestion first.
<nckx>james[m]: Or! Just blindly type your passphrase at that empty screen.
<nckx>Make sure you haven't typed anything (by accident) first, else reboot.
<nckx>What's happening is that the drivers to display whatever went ‘wrong’ (which I just realised could just be the second passphrase prompt) aren't loaded yet, so the kernel can't tell you anything.
<james[m]>I think its stuck in the grub boot or something.
<nckx>I don't, but there's no way to tell.
<james[m]>Because I selected the Linux libre kernel.
<nckx>I wasn't kidding about second decryption. You need to enter your FDE passphrase twice on Guix System for extra security, but mainly because bug.
<james[m]>It got as far as decrypting it and trying to boot the image.
<nckx>And probably did boot it successfully.
<nckx>See above.
<james[m]>nckx: Wait. The same FDE twice?
<maximed>james[m]: Yes, because grub currently has no way for passing the keyphrase to linux to luks
<james[m]>yea. But I don't even see that.
<maximed>(possible unimplemented work-around I've heard of: ‘key files’)
<james[m]>Yes. They should have the first part use passphrase. And the second. Use only the keyfile. That sounds like a good idea.
<james[m]>But I am not even getting that far.
<nckx>james[m]: I already explained why you don't see it. The driver isn't loaded (yet, we hope).
<james[m]>What shall I do?
<maximed>james[m]: nckx recommended nomodeset
<nckx>That does not mean there's no prompt, only that there's no text mode to show it.
<james[m]>I don't know how to get into recovery mode on GUIX.
<james[m]>maximed: How?
<james[m]>How do I edit the kernel parameter line in grub?
<james[m]>Can I do this from the grub menu?
<james[m]>Never tried this. Will see.
<maximed>james[m]: see nckx message about the letter 'e'
<jpoiret>yes, with e
<james[m]>Okay I see the GNU with Linux libre config. But not the whole grub config.
*james[m] uploaded an image: (79KiB) < >
<nckx>Put your cursor before --root= and type ‘nomodeset ’.
<nckx>So, spaces on both sides.
<james[m]>Its the config for the image. Not the whole of grub.
<james[m]>Its the generated config. Not the default one.
<james[m]>I know guix it will be configured differently for that as its declarative.
<james[m]>nckx: Ah I see. Thanjs
<james[m]>So like nomodeset --root=/dev/blablabla
<nckx>I don't understand your two ‘Its …’ messages but let's just push forward with this for now.
<james[m]>Just checking because I don't want to mess it up.
<nckx>It's not permanent, only in RAM.
<nckx>(So this is not a permanent ‘fix’ either, but one thing at a time.)
*james[m] uploaded an image: (86KiB) < >
<james[m]>Yea I know. I will need to edit the system config to make that perminant. Something with system-configure I think it was if I recall.
<nckx>Looks good. Now hit Control + x to boot.
<james[m]>Nothing so far....
*nckx 🤞 harder.
<james[m]>How can I see the journal log?
<james[m]>I guess the kernel is not really booting or no way I can reach a tty yet. As still in grub type thing.
<nckx>I really don't think so, but since we don't have output I can't prove it either :)
*james[m] uploaded an image: (1418KiB) < >
<james[m]>Its the same.
<nckx>james[m]: You'd normally see the kernel log scrolling by, but… no graphix. And since file systems aren't mounted there are no log files at this early point.
<james[m]>Yea. That's what I feared.
<james[m]>Will be nice when Hurd becomes suitable enough for my PC.
<james[m]>At least if something crashes its quite tolerant to that. But that's a separate thing I won't go into.
<james[m]>So what shall I do now?
<nckx>james[m]: Reinstalling with the exact same set-up won't magically fix this. Reinstalling without FDE might. Can you afford to do so for now? We can also wait a bit for others to chime in; I'm currently out of ideas.
<nckx>I don't own any ‘modern’ hardware and I don't really mind. But I'm sorry I can't be of more help.
<james[m]>Hmm. I can try doing it that way first. But my personal computer will need FDE.... (full message at
<james[m]>Will try that...
*james[m] uploaded an image: (61KiB) < >
<nckx>james[m]: I understand. Sorry for the lack of ideas.
<james[m]>No worries,
<james[m]>Here is the config. Anyway. Just while I wait.
<james[m]>What IDEs do you guys use for Software development?
<james[m]>This is very much GNU, so I can probably guess.
<nckx>Guilty, although I use it as a text editor more than an ‘IDE’.
<lilyp>much GNU
<lilyp>That being said, we did package gnome-builder for those who like pointy-clicky things
*nckx AFK to fiddle with their own graphix.
<james[m]>Yea. I should have said that.
<james[m]>I am using pycharm and intelij. At the moment. The community edition.
<james[m]>But I use Emacs for assembly language programming because it excells at everything if you configure it right. And if I only need it for assembly. Its less work and it works really well.
<james[m]>I would love to use Emacs for all my text editing. Including all my programming.... (full message at
<james[m]>I find it hard to do though.
<james[m]>Of course I use the community edition of them. No non free stuff on my PC of course.
<james[m]>As far as software goes.
<lilyp>to be fair, it'd probably be simpler to configure emacs right than to get jetbrains anything to build from source :)
<james[m]>lilyp: Does jetbrains have binary blobs BTW?
<james[m]>Yea but even then I would would to contribute my patch as it would be useful to others as well. Someone was actually working in making a definition for it it was in some GUIX mailing list.
<james[m]>I think its a good piece of software. The community libre edition that is.
<lilyp>I don't think you'd get that far, what with the Kotlin bootstrap and everything
<nckx>podiki[m]: So it took a while (to rebuild the world on a travelling laptop — who'd've thought) but I'm successfully running your Mesa 22.1.2 patch with <>.
<nckx>VAAPI works too.
<efraim>nckx: don't wait for me to review the other architectures of the patch. I always build out to mesa on all My platforms before a core-updates merge.
<james[m]>I do like using the UI for text editing I must admit. Although I learn key bindings. And probably could get quite good that way.... (full message at
<nckx>efraim: OK, I was just going to build-test them.
<efraim>aarch64 has gotten faster over the years but riscv64 can be slow and powerpc is awful
<efraim>I still need to get my mips64el box reconnected
<james[m]>So do you guys think switching to emacs would be better?
<james[m]>Could I make it feel similar to Intelij Idea?
<james[m]>Not all of it. Just the main things I like.
<nckx>podiki[m]: I tried to write a diplomatic comment for auto, because I don't blame upstream for being all ‘patches welcome’ on other arches.
*efraim uses vim
<lilyp>I think trying out GNOME Builder and reporting bugs might a good intermediate step if you need pointy-clicky
<nckx>efraim: Do ‘we’ have any project-{owned,accessible} riscv64 systems?
<james[m]>I've used gnome builder before. For C programming I mainly used it.
<efraim>Hmmm, I don't think so
<nckx>Jives with what I thought.
<lilyp>but long term, emacs/vim will survive another three generations of new hype editors
<efraim>We might consider a few of these
<james[m]>efraim: That's good. Yea I use vim as well sometimes, only know basic but I use it all the time on servers. But for IDE stuff its not what I am looking for.
<maximed>What do people prefer: ‘build driver’ or ‘compiler’?
<james[m]>lilyp: Yea. They are the best text editors in terms of power in my opinion.
<james[m]>Different philosophies but its like ying and yang. Someone can at least be comfortable with one of them.
<nckx>maximed: I know what one of those words mean, for example.
<james[m]>Anyway. Time to see if my system will work....
<maximed>nckx: In the hare patch ‘Hare programming language build drier and standard library’ was used.
<maximed>I don't know either.
<nckx>efraim: Interesting. I have no idea what to expect from something like that, subjectively, performance-wise.
<maximed>I assume some kind of synonym for compiler ...
<lilyp>fwiw I don't think the hare package includes the compiler
<nckx>Not useful:
<nckx>'The build driver is responsible for collecting input files, resolving their dependencies, and producing a plan for compiling your program.' —
<nckx>Seemingly not synonymous.
<podiki[m]>nckx: glad mesa worked, and for wayland seems it is just that one test for you?
<podiki[m]>nckx: and yes, a code comment for auto (besides commit message) makes good sense!
<maximed>nckx: Can I quote you in e-mail
<maximed>(OTOH, technically 'gcc' isn't the compiler but 'cc1' is ...)
*maximed assumes yes, because we have
<nckx>maximed: I'm just quoting someone else.
<lilyp>ahh, but it's the GNU compiler collection :P
<nckx>Now finally back on laptop, I can find obvious results 😛 I think we should use in-universe terminology where accurate, not try to impose a C worldview.
<james[m]>Hmm, I guess I will make the leap to try emacs again.... (full message at
<james[m]>I know Emacs can do anything. But would these features be easy enough to setup?
<lilyp>james, please try to send messages line by line rather than huge blobs
<lilyp>it's somewhat annoying having to switch to a browser every time ^^"
<james[m]>lilyp: Sorry.
<nckx>james[m]: This is how they appear to us:
<nckx>Not a shooting offense, but a bit of friction each time it happens adds up.
<nckx>(There are no shooting offences in #guix, I think, but people will start humorously listing ones if I say so out loud…)
<james[m]>I forget people use more minimal clients or its just how IRC works with Matrix.
<james[m]>Sorry about that.
<lilyp>anyway, for autocomplete, I'd suggest corfu, assuming that minimal is enough
<rekado>(does this look good in any client other than matrix?)
<nckx>james[m]: No apology needed, but now you're aware.
<lilyp>other than that, you could try to set up lsp-mode, which mimics the way vscode does things
<james[m]>rekado: Matrix is not a client. Its a protocol. I am not using IRC directly to be here.
<lilyp>syntax-highlighting should be there ootb for most languages, includig python
<rekado>*other than a matrix client
<rekado>I’m aware that Matrix is a protocol
<lilyp>for graphical debugging, there's gud, which is really gud :)
<james[m]>lilyp: Yea I've looked at that. But my problem with vscode was its not really a IDE in my view.
<james[m]>lilyp: Yes it is. I like it very much. If you mean the one that comes with it. And uses gdb I think as backend.
<lilyp>what counts as an IDE vs what doesn't subjective
<lilyp>IIRC gud can also be made to work with the python debugger
<james[m]>Yea I need to install something though. Right?
<lilyp>For gud? I don't think so
<james[m]>lilyp: Everyone's criteria is different. But the idea is it needs to be suitable for full stack development. And stuff like a debugger is often a requirement for most people.
<james[m]>Okay. Trying my system... Hope it works.
<lilyp>I don't know if vscode has a debugger, but it does have "smart autocompletion" which is the one feature people use IDEs for.
<james[m]>For something to be an IDE. There are some requirements which are common.
<james[m]>Otherwise its a "Code Editor"
<james[m]>Which just means its useful for programming.
<james[m]>An IDE. Is integrated. Meaning its designed to work for that language, etc. The whole development process is taken into account.
<james[m]>Okay my system works now. But I do need FDE.
<nckx>Full-Disc Encryption.
<lilyp>ahh, thanks
<nckx>They installed with, earlier, but boot stalled without graphics from the kernel (which was probably fine, but had no mouth to scream about that).
<nckx>Now I wonder if adding the graphics driver module to the initrd would suffice.
<nckx>Knowing that it works just fine.
<unmatched-paren>maximed: "build driver" means "a program that organises the build and runs the compiler"
<sneek>unmatched-paren, you have 2 messages!
<sneek>unmatched-paren, jgart says: > (nonfree source) Matlab instead of (free source) Octave
<sneek>unmatched-paren, jgart says: I don't really use any of thosse programs. That was mostly for dcunit3d_ who needs them. I'd probably use Octave but I imagine dcunit3d_ needs some feature of Matlab that Octave doesn't provide maybe or it's a requirement for some class or whatnot
<unmatched-paren>harec is the compiler
<unmatched-paren>hare runs the build
<unmatched-paren>harec makes QBE files from Hare files
<unmatched-paren>with harec, you need to run it for every file, then `qbe` and `as` it
<unmatched-paren>and `ld` of course
<unmatched-paren>with hare, you just run `hare build`
<unmatched-paren>that's the point of a build driver
<lilyp>oh, so it's just another make?
<unmatched-paren>it's the difference between `go build` and `go tool compile`
<unmatched-paren>lilyp: hare stuff typically includes a makefile
***ChanServ sets mode: +o litharge
***litharge sets mode: -bo $a:betelgeus*$#guix-fix-your-connection litharge
<unmatched-paren>which calls hare build
<unmatched-paren>so that extra tasks other than building .ha files can be run
<lilyp>is this like the infamous all: cargo build makefiles?
<unmatched-paren>I suppose, though `hare` doesn't read a build system config file
<unmatched-paren>it just scans for Hare files and builds them all
<unmatched-paren>Hare projects are arranged in a very regular way, so there isn't much point in writing rules for .ha -> .o in the makefile
<unmatched-paren>(e.g. executables are always in `cmd/` afaik)
<unmatched-paren>The crucial difference that makes `hare build` not suck is that it doesn't try to download dependencies
<unmatched-paren>Hare expects you to use a real package manager for your dependencies, thank goodness
<lilyp>well, sure, but I still feel as though the accomplishments of hare build might be overstated?
<unmatched-paren>what do you mean by that?
<unmatched-paren>it doesn't really try to do much
<lilyp>and that's exactly the point
<lilyp>if you don't need to do much, you could for instance ship with the magic to make things work for autotools, meson, etc.
<lilyp>focus on providing the necessary glue rather than adding yet another build system
<unmatched-paren>harec is the necessary glue
<maximed>From what I've heard so far, 'hare' looks like a wrapper around a compiler to me (to pass appropriate -L flags, etc.).
<maximed>I count a basic wrapper around a $foo as a $foo (with the internal $foo considered an implementation detail)
<unmatched-paren>hare build's job is to allow you to build things using a makefile without repeating the same logic again and again
<maximed>(unless it supports tons of underlying compilers and you can choose or something)
<maximed>unmatched-paren: Looks like 'make', except specialised to Hare?
<unmatched-paren>maximed: It resolves dependencies and stuff, sure
<unmatched-paren>that's its main job
<nckx>Oh good.
<unmatched-paren>Dependencies between files, I mean.
<maximed>If so (about 'make'), I don't see the ‘build driver’, unless ‘make’ and ‘ninja’ etc count as ‘build drivers’.
<nckx>…oh, I missed your ‘not suck’ comment.
<nckx>Not suck? Good.
<unmatched-paren>Not dependencies between projects.
<maximed>(Maybe they (= make, ninja) do, I'm not familiar with the terminology ‘build driver’)
<unmatched-paren>I guess you could call the combination of `make(1)` and a makefile the build driver for your project
<nckx>Intuitively, make etc. is a ‘build driver’.
<unmatched-paren>of course, without the makefile, the user could still build your project
<lilyp>autotools resolves depedencies, plain make doesn't
<nckx>What else would you call it.
<unmatched-paren>but they'd have to `cc` every file
<unmatched-paren>and it wouldn't be fun
<lilyp>fwiw gcc can be invoked to tell you that info
<nckx>tsort FTW.
<unmatched-paren>nckx: DO
<maximed>Does someone have a definition of ‘build driver’? I'm now wondering if 'driver' means the same there as when people speak about ‘using $OS as daily driver’ ...
<unmatched-paren>nckx: Do you really think an Alpine Linux package maintainer would be particularly inclined to make a system that's incredibly annoying to package? :)
<nckx>They don't.
<lilyp>that's what we're all trying to understand here
<unmatched-paren>Seems like many of the annoying systems come from Mac and Windows users
<unmatched-paren>e.g. I see a lot of Node developers seem to use Mac
<nckx>‘Daily driver’ is an annoying meme than can die now. ‘Build driver’ is clearly trying to communicate that this is the tool top-level that coordinates the build by invoking lower-level ones.
<nckx>*top-level tool
<unmatched-paren>Argh, I'm trying to `wl-copy` the hare(1) manpage, which will probably explain why it exists
<unmatched-paren>but it won't connect to the Wayland server
<nckx>Welcome to my hell.
<unmatched-paren>because i'm in a --pure shell
<nckx>Actually, it mostly works for me now, so I can't complain.
<unmatched-paren>but outside the --pure shell I don't seem to be able to access the manpage?
<nckx>…time for a non-pure shell?
<unmatched-paren>Surely non-pure shells should reload the manpath or whatever it's called?
<nckx>They should append to it IIUC.
<unmatched-paren>They don't seem to
<nckx>Did you include man-db? Probably, if it works with --pure.
<unmatched-paren>Yeah, it works now
<unmatched-paren>man hare:
<nckx>Too late.
<unmatched-paren>Oh, well.
<nckx>Señor Lag at your service.
<unmatched-paren>Basically, the point is to figure out which files to compile, and then execute harec, qbe, as, ld on them
<unmatched-paren>Annoyingly harec doesn't seem to have a manpage.
<unmatched-paren>I guess it makes sense; it's a temporary solution while they get the self-hosting compiler working.
<unmatched-paren>(Well, not exactly temporary; they plan to keep maintaining harec as a bootstrap path.)
<nckx>unmatched-paren: <Do you really think an Alpine Linux package maintainer would> My complete Alpine experience is yesterday days old; I wouldn't know. I tried to apk add cowsay and it said no such package, so I wasn't impressed by their priorities so far.
<nckx>unmatched-paren: Phew.
<lilyp>do they not even have lolcat?
<unmatched-paren>nckx: I hope they at least had fortune!
<unmatched-paren>Otherwise it can't be a real distro.
<nckx>It's in ‘Edge’, apparently.
<lilyp>the fortune to cowsay pipeline is one of the most striking features of the modern linux distribution
<nckx>unmatched-paren, lilyp: lolcat no (but also in ‘edge’), fortune yes.
<lilyp>such and edgy distro
<nckx>Apparently the next release is going to be huge.
*nckx adds lolcat to their log-in fortune invocation.
<lilyp>take a screenshot, please
<nckx>"A spokesman for the Lyon Group, producers of _Barney and Friends_, denied that Barney is an instrument of Satan." — looks even better in rainbow.
<unmatched-paren>fortune | lolcat | cowsay :)
<nckx>You'll have to use your imagilation.
<lilyp>unmatched-paren: why not fortue | cowsay | lolcat?
<nckx>lolcat turns off colours when outputting to a pipe.
<unmatched-paren>nckx: then... what's the point???
<nckx>So | lolcat | won't do nuffin.
<nckx>lolcat -f works.
<nckx>Of course it confuses cowsay's width calculations.
<lilyp>we need to patch cowsay to make this happen :)
<unmatched-paren>Let's add a bug for this and mark it `critical`.
<nckx>That implies reimplementing a (likely buggy) parser for escape ANSI codes in cowsay. Seems fitting. Go for it.
<lilyp>imho "severe" is enough
<mitchell>I think i found my new favorite way of displaying FOUO banners on my servers
<unmatched-paren>lilyp: It is imperative that the text of the bug report is piped through cowsay before it is emailed to the list.
<lilyp>in cowsay?
<nckx>Oh weird, that run cut out stderr for absolutely no reason.
<nckx>It said Error reading input file "guix/README": Invalid or incomplete multibyte or wide character
<nckx>But not then.
<nckx>This is really great software 👍
<lilyp>guix show lolcat | guix shell lolcat -- lolcat
<nckx>Clearly, it should automatically invoke TTS when encountering IPA.
<nckx>I don't know how to break this to you
<nckx>but top | lolcat works and you should all run it forever.
<lilyp>it's june, all output shall be piped through lolcat
<unmatched-paren>(1) `top | lolcat` (2) hold down up arrow
<nckx>Pity htop, which I actually use, doesn't work.
<unmatched-paren>`nano | lolcat` actually works too
<unmatched-paren>although you have to use the emacs keybindings because the arrow keys don't work...
<nckx>emacs -nw | lolcat is interesting, in that I can't say off-hand how it manages to completely control-code its way out of lol.
<nckx>Oh, you had the same idea but more luck.
<unmatched-paren>Umm, it sort of works.
*nckx switching to nano, oh well.
<unmatched-paren>You can't scroll up.
<nckx>Live fast.
<nckx>Nobody needs to see what they wrote in the past.
<lilyp>folks, I have the truth:
<lilyp>ed | lolcat
<unmatched-paren>lilyp: I was just doing that :(
<lilyp>interestingly not even emacs -batch | lolcat works
<lilyp>you need to pipe stderr
<nckx>I tried that?
<nckx>Oh, -batch.
<nckx>OK, ‘works’, but -ENOFUN.
<nckx>sl | lolcat is nice but I'm clearly out of ideas.
<unmatched-paren>python3 2>&1 | lolcat ?
<unmatched-paren>(should we move this to #guix-offtopic? :P)
<lilyp>no, this needs to be documented for future generations
<unmatched-paren>Let's create a transcript of this discussion and upload it to
<lilyp>"transcript", as though the logs weren't already public
<unmatched-paren>Okay, let's upload today's log to Unless it's already automatically archived?
<nckx>But it belongs in a museum.
<nckx>(should we move this to #guix-offtopic? :P) Found the cop.
*nckx …I think it's OK as long as there's nothing else going on, but correct me if I'm out of touch.
<the_tubular>nckx completly out of the blue, but could you show me how you made your website "homepage" one day ?
<the_tubular>I like it
<nckx>the_tubular: Thank you! However, what you view (source) is exactly what I wrote to index.html (in emacs). There's nothing more there. I didn't make the background; it's borrowed from a 64K demo (by… I want to say Mercury?) without permission.
<nckx>Sorry to disappoint.
<nckx>Happy to disappoint.
<nckx>I guess I should use CSS animations nowadays. I'm very confused that you like this non-thing. But flattered.
<nckx>podiki[m]: I was about to report severe screen tearing with the new Mesa… but then noticed that the tear is baked into the video. Wat.
<the_tubular>It's clean and simple.
<nckx>Just like me.
<james[m]>Is it just me or is gnu icecat dangerously out of date. I have version 78.10esr.
<james[m]>And I am on a fresh system ran GUIX pull and guix package -u
<unmatched-paren>james[m]: I have 91.10
<unmatched-paren>hmm, can you please `which guix`?
<james[m]>Yea I know now. I just did an upgrade and its upgrading to 91.10.
<james[m]>How do I make sure I get the latest version of software.
<james[m]>Because I did a guix pull and guix package -u. Before I did any of this.
<james[m]>How do I see the available versions for a package?
<james[m]>Because guix show
<james[m]>Does not tell me.
<unmatched-paren>guix pull fetches the latest guix, guix package -u / guix upgrade updates the software in your profile, sudo guix system reconfigure /etc/config.scm will create a new system from the configuration file at /etc/config.scm, which will update system software
<unmatched-paren>james[m]: sure it does. `guix show icecat` shows "name: icecat" then "version: 9.10.0-guix0-preview1"
<james[m]>That last one I did not do.
<james[m]>It didn't for me before.
<unmatched-paren>james[m]: that only matters for things like linux-libre
<unmatched-paren>which are installed in the global profile
<james[m]>I am guessing this was from when the iso was made.
<unmatched-paren>usually when you `guix install foo`, it'll be installed in the profile of the user that runs it
<james[m]>Has anyone here used gnu Hurd on GUIX ?
<unmatched-paren>james[m]: Yes, but don't expect it to be practical anytime soon :P
<unmatched-paren>You need to run it in a VM.
<james[m]>I was worrying about the drivers.
<james[m]>How's the rest of it?
<unmatched-paren>In fact, don't expect it to be practical ever.
<james[m]>What do you mean?
<unmatched-paren>The Hurd is probably never going to be improved to the point where it's usable. That's my pessimistic (realistic?) viewpoint.
<unmatched-paren>It doesn't even support 64-bit machines!
<unmatched-paren>Nor graphics.
<unmatched-paren>s/graphics/Xorg or Wayland/
<unmatched-paren>What I'm saying is: the Hurd was probably a lost cause from the moment GNU decided to use Linux. And even before then, it was getting nowhere (iirc) and being derided as vapourware by some.
<james[m]>That's really unfortunate because its a good design in my opinion. I guess they just need more people working on it.
<unmatched-paren>The efforts to get it working are valiant, but IMHO probably ultimately pointless.
<james[m]>I don't believe it was going nowhere.
<james[m]>I think its the fact that people left that project to work on the Linux kernel. I mean if you look at the git logs there are not many people working on it.
<unmatched-paren>james[m]: Well, the reason GNU eventually fell back to Linux was that Hurd was taking a loooong time. And, I think, the reason that Linux was created in the first place; apparently Linus wanted a UNIX that ran on x86 computers, but Hurd was nowhere near done.
<james[m]>It has potential in my opinion.
<james[m]>Its difficult. I think eventually it will be useful for daily use.
<james[m]>When, I do not know. I will be following it at least.
<james[m]>If you look at the design its actually very well designed. But I get how its difficult to do.
<james[m]>The no x86_64 yet bit is disappointing.
<unmatched-paren>It is a shame, it's well designed, I agree.
<singpolyma>There are a lot of nice kernels around. Linux just has this bonkers amount of hardware support that no one can match
<sneek>singpolyma, you have 1 message!
<sneek>singpolyma, jgart says: I think I may have misunderstood how `hidden-package` works...
<singpolyma>sneek: you're drunk, that was another channel
<james[m]>The idea was to create something a bit like the Incompatible Time Sharing System. Type philosophy. Where users actually can't be restricted. Its all about freedom 0. As they said.
<james[m]>unmatched-paren: I would still recommend that video I sent you.
<james[m]>I think it provides some hope.
<unmatched-paren>singpolyma: sneek is cross-channel
<james[m]>Its a bit of a chicken and egg situation. If you want it to get more development you need popularity and appeal. To get that. You need lots of development. And so on.
<singpolyma>unmatched-paren: sure, but messages out of context make no sense. I only understand that one because I already saw it in my history on the other one
<unmatched-paren>james[m]: I did find that interesting that they have plans. The question is whether those plans will ever be realized.
<james[m]>unmatched-paren: I recommend the video to you.
<james[m]>Yes its being worked on. But not by many people.
<KarlJoad>What is the proper way to specify a networked filesystem to be mounted? I understand it would go in the file-systems field of the OS definition, but am unsure if there is something special that must be done.
<lilyp>you would need to set the nfs type and probably also make it not mount at boot
<KarlJoad>Are other filesystem types supported? Samba/CIFS, namely. I have control over the server, so I can set up NFS, but am lazy.
<lilyp>we do have samba packages, but I don't actually know the mount options to do things by hand
<lilyp>(I usually rely on gvfs, which works as expected in Guix)
<james[m]>Does anyone here have experience with virtualization in guix?
<james[m]>I want to use Xen. And just wanted to know if anyone had issues setting it up or if its just as simple as on Debian.
<james[m]>*Guix System
<maximed>james[m]: There's "guix system vm ..." that automatically create script for starting a VM from a given configuration (under QEMU, not Xen, I don't know Xen)
<maximed>there's also a libvert-service-type
<maximed>* libvirt-service-type
<maximed>james[m]: You can also do "guix search xen" which lists some relevant packages.
<james[m]>Okay. That's nice. But I want to essentially use my system similar to Qubes in that I want to compartmentalize stuff.
<james[m]>I know that's hard in some ways. But basically I want the best way to interface with my VMs.
<james[m]>Before, Virt-Manager was the best.
<james[m]>I think this guix system VM thing is interesting.
<maximed>I don't know much virtualisation beyond "do guix system vm-image and run it under QEMU / GUI wrapper for QEMU".
<james[m]>I need a bare metal hypervisor with really strong security able to be achieved.
<james[m]>Xen is the only hypervisor with the ability to achieve that. That I know of.
<james[m]>maximed: I think its essentially running the KVM/Qemu command behind the scenes or something.... (full message at
<james[m]><maximed> "there's also a libvert-service-..." <- Yea. I might need some help with that.
<james[m]>I know guix is tolerant to mistakes but I really don't want to mess things up in my system config.
<james[m]>Because I am not that apt, with guix.
<justkdng>libvirt requires a running daemon for usage, libvirt-service-type basically starts that daemon boot
<justkdng>you can use kvm and xen with libvirt it seems
<justkdng>never used xen before though
<james[m]>justkdng: Yes of course, I should have said that. Yes. Most hypervisors, libvirt supports.
<james[m]>justkdng: I will be honest. My experience is once its installed and the daemon is started. It works.
<james[m]>Its not much harder than KVM in my experience. As far as getting it working.
<james[m]>I don't know about on Guix system though. I am used to Debian and Arch based distros.
<justkdng>I guess you also need polkit configured to be able to auth to the daemon
<james[m]>Is that the same with KVM as well then?
<james[m]>I hope Xen is similar to KVM as far as initial setup goes.
<justkdng>no, that's a libvirt thing
<james[m]>justkdng: So yes then. Its the same?
<james[m]>Libvirt supports lots of hypervisors so if I only need to do libvirt stuff and just specify xen as a hypervisor it should work. Right?
<james[m]>Could someone give me their config for virtualization?
<james[m]>Even if its just KVM. I think it will help me learn a bit more.
<james[m]>I am also looking at the manual. But this would complement it.
<james[m]>You can redact the other system config stuff. I only am interested in the virtualization stuff that I need.
<james[m]>I can adapt it for xen.
<vagrantc>i seem to recall a bug in libvirt relating to it embedding the full path to qemu at creation time of the virtual machine (which would get guix gc'ed away out from under the virtual machine)
<vagrantc>not sure if that was ever fixed to, say, use guix system's path in /run/...
<vagrantc>i don't think libvirt can use a relative path ... otherwise that would be a better solution for guix
<nckx>So libvirt VMs aren't even reliably portable across machines?
<james[m]>Well at the moment I am still on the updating process using guix refresh.
<james[m]>It keeps saying service not found or something. Then the guix refresh stops. I run it again. And it gets furthur. But happens again at some point.
<james[m]>Well, at least its updating the definitions.
<james[m]>Also there is a. Github rate limiting.
<james[m]>I don't feel great about github being the main place free software resides.
<james[m]>Too centralised. What would happen if suddenly all github servers were destroyed somehow or corrupted?
<james[m]>Its unlikely. But in that case. I think it would cause a lot of problems.
<jpoiret>james[m]: there's swh as a fallback
<jpoiret>that same issue would happen with any other host, and you could argue that GH is the one that's least likely to go offline
<james[m]>jpoiret: Don't know what that is. But I am glad there is a fallback.
<jpoiret>software heritage, see
<james[m]>jpoiret: I was not suggesting we replace github with another host.
<james[m]>jpoiret: Thanks.
<james[m]>jpoiret: I mean. The git protocol is decentralised. So why not make the git interface that too.
<james[m]>Maybe its something to be made in GNUnet. It would be a good place to experiment with something like that as its the right environment.
<mitchell>does anyone know why glibc doesn't install man pages? man 2 printf does not return anything
<maximed>james[m]: I've done some work on that (actually, for fixed-output derivations instead, but for Guix that would be sufficient for downloading source code), not completed though ...
<maximed>(the Scheme interface to GNUnet services need more work)
<maximed>mitchell: I don't think glibc has man pages at all
<maximed>It uses 'info' instead.
<maximed>You might be searching for 'man-pages' (IIRC) instead, which is independent of glibc
<mitchell>oh. Where does ubuntu get its man pages for the libc functions?
<mitchell>I miss them
<maximed>mitchell: Probably from man-pages.
<justkdng>yeah, man 3 printf says so
<justkdng>This page is part of release 5.13 of the Linux man-pages project.
<mitchell>thank you
<maximed>mitchell: probably from, try "guix show man-pages"
<mitchell>that's exactly what i was looking for
<jpoiret>james[m]: there are experiments to use IPFS and other decentralized file systems in Guix
<james[m]><maximed> "james: I've done some work on..." <- Nice. Yea. At the moment I only know enough to do minor bug fixes and stuff. Its quite intimidating as I am new to that. I also attended the virtual hacker week that happened when everything when online.
<james[m]>Also I keep getting errors when I do a guix refresh. Is that normal?
*james[m] uploaded an image: (155KiB) < >
<justkdng>I believe the apropiate way to update guix is to guix pull then hash guix and then sudo guix system reconfigure ${system conf}
<justkdng>at least that's how I've been updating my system packages
<maximed>james[m]: Error reporting in Guix often isn't great, but that's a bug, not some intended feature.
<james[m]>Okay. Will do that. Also latest version for Python is 3.9.9.
<james[m]>So close to the version I want. 3.10.0.
<james[m]>I need pattern matching and switch statements(match).
<maximed>Also, for sharing text, I recommend something like
*yewscion is back (gone for 15:45.31)
<james[m]>maximed: I figured. But sometimes errors just happen due to user error and are minor. Is what I meant.
<james[m]>Because it would continue to try and fine new versions.
<maximed>james[m]: That, and just say 'gnu/package/...: xlockmore could not be investigated because the remote server is inaccessible (name resolution failed)’ or something like that.
<maximed>instead of backtrace.
<maximed>Looks like there's quite some things that can be updated ...
<james[m]>How do I get Python 3.10.0 then. Because it said that 3.9.9 was the max?
<james[m]>Bit odd if you ask me
<maximed>Maybe "guix refresh" looks in the wrong place?
<maximed>The refreshing logic for where to look & how to detect versions can be fragile and heuristic at times.
<maximed>Which can sometimes be corrected by setting some appropriate package properties.
<maximed>Or maybe something else is going on.
<james[m]><justkdng> "at least that's how I've been..." <- That only impacts system. Packages I think. I need updated version of python. And userspace stuff too. So I am using refresh to get the newest package definitions.... (full message at
<maximed>james[m]: IRC does not have multi-line messages.
<justkdng>guix's latest python is 3.9.9
<justkdng>someone has to send a patch to update it to 3.10.x
<justkdng>I was using guix package -u to update user packages
<james[m]>justkdng: Could someone do that?
<james[m]>I am teaching someone programming and it would be very good if I could use 3.10 because of the pattern matching.
<james[m]>Its the last thing that python was really missing that was essential.
<james[m]>Using if statements or looping through an array is not good practice to teach. For switch statements.
<james[m]>There are not really any good practice workarounds.
<james[m]>And I've looked.
*mbakke has plans to upgrade Python on the 'core-updates' branch, but it won't land in 'master' until a couple of months
<maximed>james[m]: FWIW, you can make a _local_ ‘variant’ of the 3.9.9 definition (for 3.10)
<maximed>and put it in a manifest or something
<maximed>then do "guix shell -m manifest.scm -- python3"
<james[m]>mbakke: That's too late. They will be back at school by then. And I will be at uni. And will be busy.
<maximed>(so waiting for it to be applied in Guix isn't needed)
<james[m]>So I edit the file where the definition is stored on my system. Then run that on it.
<maximed>(package (inherit (specification->package "python")) (source ...)) may be useful here ...
<maximed>james[m]: You can do it that way, but that's more complicated, you have to make a git clone of guix and run ./configure & make etc
<maximed>So I think for now doing things locally in a manifest would be simpler.
<james[m]>I am new to this. So I think I have a lot to do already. Getting xen working. And intelij idea.
<james[m]>Yea. The simpler would be better.
*maximed searches for example ...
<james[m]>I am a newbie. And I don't write guile scheme. I have used racket before which is based on scheme. But did not become great at it.
<james[m]>I think if I made this manifest file and it worms, I will post it somewhere because likely someone else has this issue.
<james[m]>Perhaps on my website as well as guix mailing list or something.
<justkdng>for intellij I think getting jetbrains-toolbox to work is the simplest solution
<justkdng>then again, jetbrains-toolbox is just a glorified web application that just extracts itself to /tmp
<justkdng>you could run it without packaging it
<james[m]>justkdng: That promotes nonfree software. I can't add that to guix as a patch.
<james[m]>I think I would be denied that request because of the FSDG.
<maximed>james[m]: I've found something and trimmed it down a little (untested, also bogus for libgit2 but should be (almost?) fine for python3):
<james[m]>I want to help myself but also others. So it has to work for them.
<justkdng>you could help fellows that like guix but need non free software, but that's offtopic here
<james[m]>maximed: Nice. I will try that.
<vagrantc>nckx: well, it's trivial to change the full path in the virtual machine .xml definition ... but under a system using FHS or whatever, the path to qemu doesn't usually change very often
<james[m]>justkdng: I am not going to promote nonfree software to people. I want the free software to work better and more of it to be available.
<james[m]>Nonfree software only unfortunately can be a dependency if the hardware is an issue. Through nonfree drivers.
<james[m]>I have an ongoing project to make Microsoft Access databases work in libreoffice Base. Out of the box.
<james[m]>Using Jackcess and UcanAccess as the back end. The goal is people won't need to use MS Access anymore to connect to those databases. Whether remote or file.
<james[m]>But this will also include Forms,Queries and Reports. Not just tables I should point out.
<vagrantc>looks like the libvirt issue was fixed
<vagrantc>or, rather, worked around
<james[m]><justkdng> "you could help fellows that like..." <- We can replace the nonfree software in most cases.
<james[m]>Sometimes its really difficult to do. But that does not mean we should give in and just distribute it.
<james[m]>My solution is to replace it. Or make a compatible program with the file format so it can be used in similar programs.
<justkdng>nonfree firmware can't be replaced sadly
<justkdng>I had to use nonfree blobs for my gpu and wifi to work
<james[m]>I am not talking about firmware.
<james[m]>In the case of intelij. The core is free software.
<james[m]>But they make variants of it which are proprietary.
<james[m]>So the intelij idea IDE. Is actually libre.
<james[m]>Pycharm is also just Intelij Idea with Python stuff.
<james[m]><justkdng> "nonfree firmware can't be..." <- Embedded software can't be replaced in practice. The free software foundation makes a distinction.
<james[m]>If the hardware has embedded software which they can't change. That's separate.
<james[m]>As long as the software on the computer is free software. Then its considered a free system. According to them.
<james[m]>I am guessing its nvidia for GPU or something. WiFi is also a problem. Generally if you don't have a laptop bought with this in mind.
<james[m]>This is a major issue.
<justkdng>nope, it's an amd gpu
<justkdng>I believe only old intel gpus don't need blobs
<justkdng>well, old hardware in general
<singpolyma>Depends what features you need
<james[m]>Is that integrated or dedicated graphics?
<singpolyma>AMD GPUs work great without blobs, but not for accelerated 3D
<james[m]>That AMD GPU you have.
<james[m]>singpolyma: Sounds like nvidias issue.
<justkdng>I'm running guix in a laptop with a 4700U
<justkdng>guix won't even boot without blobs
<singpolyma>james[m]: Nvidia you also need nonfree drivers usually even just for 2d accel
<james[m]>Yea for now.
<justkdng>userspace works great though
<justkdng>thanks to the mesa folks
<maximed>alacritty has been antioxidated
<justkdng>maximed: what do you mean?
<james[m]>I understand support for binary blobs of firmware and drivers might be worth someone doing.
<james[m]>To make it so they can use a free operating system at all. But the user needs that to be known to them.
<james[m]>Beyond that. I don't think people should spend time trying to get proprietary ELF binaries. Etc. To work on GNU/Linux.
<james[m]>We have replacements and ways to read the file formats quite often. If not. Someone can work on that.
<maximed>justkdng: antioxidant is a Guix build system, intended to replace cargo-build-system, avoiding some current problems with cargo-build-system
<maximed>A basic form of incremental compilation (but not what rust means with incremental compilation), less messy dependencies in general ...
<justkdng>Is bootstraping rust still a pita?
<maximed>TBC, antioxidant is independent of rust bootstrapping.
<james[m]>Anyway. Night everyone.
<james[m]>Nice to meet you guys. I will probably be back tomorrow. And hopefully have all my stuff working.
<james[m]>If I make any patches I will let you know. But might be a few weeks because I have not done guix for a while.
<maximed>FWIW, there is an effort in GCC to support Rust.
<maximed>(being GCC, I assume GCC's Rust support is implemented in C++, not Rust, so presumably that would resolve boostrapping trouble)
<maximed>There was some update some time ago on mrustc, for shortening the chain?
<maximed>Also, mrustc now works on aarch64-linux, so (assuming it is already merged), you can built rust stuff for aarch64-linux!
<maximed>* build