IRC channel logs


back to list of logs

<excalamus>good evening, Guix!
<excalamus>where does the 'file' command come from? It doesn't seem to be on my system.
<excalamus>I would think it's in coreutils. It isn't, though
<excalamus>nvm, it's just the first hit on guix search file
<phf-1>I've this error `PermissionError: [Errno 13] Permission denied: '/homeless-shelter''
<phf-1>while trying to install: python-libpysal:
<phf-1>Any idea?
<jgart>phf-1, grep for homeless-shelter in python-xyz.scm
<jgart>I think you'll find a solution
<jgart>maybe we should document that issue with packages and the reason for it to understand why it happens...
<jgart>phf-1, if you don't mind, let me know if you were able to solve it
<phf-1>will try that thing above
<excalamus>what is the reason?
<excalamus>I see that $HOME needs to be /tmp
<phf-1>jgart: yes, it works!
<jgart>that's it
<jgart>phf-1, you can leave off the #t
<jgart>at the end of the lambda
<phf-1>ok, thx.
<jgart>that's the common practice in guix nowadays
<jgart>excalamus, ah cool
<jgart>> inherited from Nix.
<excalamus>that sounds worth writing down somewhere. Maybe just in the source comments?
<jgart>or in a doc or both ha
<excalamus>looks like Nix has it in their docs
<jgart>excalamus, would you like to send a patch for that?
<excalamus>I can try
<jgart>can you link where you found it in nix docs?
<excalamus>it says it is in the thread I linked, but I don't see it when I follow the link. Maybe it's in an older version of the docs?
<excalamus>it's mentioned there
<Ribby>Anyone want an image of my 64 bit os installation boot attempt?
<jgart>Ribby, how are you going to share that?
<excalamus>jgart, I need to feed the dog. After, would you be willing to pair on submitting a patch?
<Ribby>Hold on.
<Ribby>A phone snapshot, a phone friendly temporary image host, and of course, a steady upload link.
<jgart>excalamus, sure, I can for a minutes today (~30)
<jgart>we can schedule something more for another time this month if you like
<jgart>excalamus, BBB?
<jgart>what are you trying to submit to upstream?
<excalamus>jgart, BBB works for me. But it sounds like it might be better for you later. I was just thinking the $HOME /tmp thing.
<jgart>Ribby, how did you build your image?
<jgart>can you share the command and config that you ran the command on?
<Ribby>I didn't I bought the usb. Needed a usb anyways.
<Ribby>That's the 64 bit boot mode.
<Ribby>But since I do have an usb, I can make my own build.
<Ribby>How's that for a start?
<jgart>I can try building it myself. Have you tried flashing the image straight from the store with dd?
<jgart>excalamus, I think that won't take long if you want to jump on BBB I can walk you through it
<excalamus>cool, same link as this morning?
<Ribby>I didn't use any commands nor config save for the BIOS or UEFI boot menu
<jgart>excalamus, this one:
<jgart>it's a different one
<Ribby>I tried burning on a cd before.
<Ribby>I can't say I have much tinkering with usb. Not even OS installation so first time.
<Ribby>What store? dd?
<jgart>I mean to burn directly from the store to the usb with dd like it shows in the documentation
<Ribby>The store just mailed the usb to me.
<Ribby>They did the burning.
<jgart>ha no
<Ribby>Oh, I don't think I visited the gnu store.
<jgart>I mean the gnu store (guix jargon)
<jgart>this can become a guix meme
<jgart>maybe we can change store to shop ha
<jgart>excalamus, I'm in BBB whenever you're ready
<excalamus> it's saying the meeting hasn't started
<excalamus> Let me poke round
<jgart>oh try again
<jgart>I started it now
<Ribby>I never done it. I am reading up on though. I guess I could start up on my own. At the least, my usb had gnu/guix somehow.
<KarlJoad>Is anyone here using certbot to generate SSL certificates for the website on Guix?
<jgart>KarlJoad, are you having issues with the certbot service in Guix System?
<KarlJoad>jgart: I have certbot-service-type present, along with configuration, but I never get any certificates generated.
<jgart>I had some issues with certbot when I was running a mumble-service-type with it
<drakonis>you might have to manually invoke the generation script
<jgart>the certs were just not regenerating
<jgart>atleast not with shepherd or whatever
<jgart>drakonis, is their an mcron service that needs to run for that?
<drakonis>i'm not aware of that
<drakonis>maybe it'd be good to write one?
<jgart>I thought certbot-service-type already has some schedule you can configure for regenerating certs.?...
*jgart reads the source
<drakonis>it doesnt seem to.
<KarlJoad>I added the certbot package too, so I could manually invoke it, but I always end up with challenges failing.
<jgart>a friend mentioned to me that they would usually invoke certbot manually
<jgart>when running a mumble server with certbot service
<jgart>since certbot service would fail to do so
<drakonis>that's what i've been doing
<drakonis>its annoying because i have to ssh into my server to invoke it
<jgart>how does NixOS do it?
<drakonis>its... convoluted.
<jgart>might be instructive to check to or not
<drakonis>its very convoluted.
<drakonis>it does not use certbot
<jgart>I think they do it some other way
<jgart>it's not called certbot... i think
<KarlJoad>I am fine with invoking it manually, but I cannot get the challenges to work using either method (webroot and standalone).
<drakonis>its acme
<jgart>ah ok
<singpolyma>Anyone got a good idea for what I should use to strip a suffix if present with guile?
<singpolyma>String suffix
<mbakke>singpolyma: (if (string-suffix? "foo" str) (string-drop-right str 3) str)
<singpolyma>Oof. Yeah. Ok
<singpolyma>Scheme is so low level sometimes :P
<jgart>singpolyma, what would haskell do?
<jgart>where is string-suffix from?
<jgart>ah it's built in
<singpolyma>jgart: in Haskell I Data.Text.stripSuffix
***califax- is now known as califax
<jgart>ah cool thnx
<jgart>learn me a haskell on irc
<jgart>singpolyma, maybe I asked this before but do you work on purescript with nix? or you use apt to install purescript stuff?
<jgart>since you're on debian
<singpolyma>You mean where does my purs come from?
<jgart>and spago
<jgart>do you use spago?
<singpolyma>I have it in ~/.local/bin/purs right now
<singpolyma>Yeah I use spago
<jgart>how do you get spago?
<singpolyma>Same. Binary stuffed in my .local/bin
<jgart>I've been using nix but I'm just curious
<jgart>ohh ok
<singpolyma>I've never tried nix
<jgart>for sharing
<singpolyma>Came here first
<jgart>I came here first, left, and then came back
<jgart>but I use nix as yet another package manager package manager
<jgart>if guix doesn't have something I ask nix until I can package it for guix
<jgart>or I ask xbps
<jgart>for the binary
<KarlJoad>So is there a solution(?) for certbot? I can share the webhost's config.
<Ribby>Alright, I'm going to reflash this usb. Maybe it's the wrong version for my hardware.
<xelxebar>Man, when building packages from the git repo, I've lately been getting random segfaults :/
<xelxebar>s/packages/my package/
<Ribby>bad server, I think.
<lfam>segfaults are unexpected and definitely should not be affected by any server
<xelxebar>They tend to cluster. I just got three in a row, but as soon as I tried to run strace, they went all Heisenbug on me and stopped happening.
<lfam>It happens when building your own package?
<Ribby>I say to try another different server, git does have to get big to host all those projects.
<xelxebar>Looks to be happening while *evaluating* my package definition.
<lfam>Does it ever happen with any other package?
<Ribby>By itself?
<lfam>Also, when you say evaluating, what do you mean?
<xelxebar>When the segfault doesn't happen, I get an error: warning: source expression failed to match any pattern
<lfam>I see. So, it either crashes or segfaults?
<Ribby>I don't do repo or repositories. It's a setup requiring sensitive details regarding automatic downloading and installation.
<xelxebar>Exactly. This is the third (?) time I've seen this, and I vaguely think they've all happened when the same error pops up.
<xelxebar>Ribby: I just pulled master maybe an hour ago.
<Ribby>One of the urls might have messed.
<Ribby>Master doesn't mean it is complete, but it can be regarded as to prevent automatic program execution.
<xelxebar>lfam: Unfortunately, I haven't recently tried building from the repo any package other than my own, so can't provide a lot of comparison.
<lfam>xelxebar: Even if your package isn't written correctly, and should be expected to crash, it definitely should cause a segfault. I would report it to #guile
<lfam>I mean, it shouldn't cause a segfault!
<Ribby>Usually, software installation misses the dependency/support files. It's a meta thing.
<xelxebar>Yeah. Segfault is bad. But I don't think I can report anything useful at the moment, "Hey guys, I'm getting segfaults. Bye."
<Ribby>"Ah, more details", they asked.
<xelxebar>Would like to crank up logs, but not sure *where* is most reasonable. guix-daemon? guile itself?
<Ribby>As long its evidence, it's evidence.
<Ribby>Profound evidence is even better.
<lfam>xelxebar: Since your package definition never works, it's a code sample that can be used to reproduce the failure
<lfam>Like, your modifications and the Git commit they are based on together give a more complete reproducer than almost any bug report
<Ribby>Just remember to note the hardware specifications as well as the bootloader software stuff. Things can be different given the Linux brands branching off a bit.
<apteryx>seems the CI has slowed down to a halt
<xelxebar>lfam: Ouch. That sounds like a painful truth. Okay. I'll try to wrap the details up and put a bow on it for bug-guix.
<lfam>I agree with Ribby, details about your hardware will be useful too
<lfam>If convenient, I would run memtest overnight, to make sure it's not a hardware problem
<lfam>xelxebar: Beyond reporting the segfaults, people in this channel can help get your package definition working
<apteryx>oh I guess it's done building version-1.4.0 for x86_64:
<xelxebar>lfam: Good idea. Might just be evidence of failing hardware.
<apteryx>we're 3% shy of master... Seems there's lots of pending aarch64 builds, but the machines are idle... Arf.
<singpolyma>I'm getting "Git error: no content-type header in response" trying to do a go import. Does guix git integration require "smart" URLs?
<lfam>Do you mean smart HTTPS Git repos?
<xelxebar>lfam: Hah! In the course of formulating a question about the problem with my package definition. I figured out the problem. :D
<lfam>It often happens that way!
<xelxebar>Had a procedure that took in args and produced a gexp. Figured out a way to remove the need for args, so changed from (define (foo a b c) ...) to (define foo ...). But I had a docstring on my procedure, which I forgot to remove.
<lfam>So, that caused the crash
<lfam>The segfault is still interesting
<singpolyma>I have a proper patch for #52362 finally
<jgart>what does $ mean in a match block?
<xelxebar>jgart: A record matcher
<xelxebar>See section 7.8 Pattern Matching. The documentation for `match' is really thoroughly laid out :D
<xelxebar>section ... of info guile.
<jgart>so it matches any record?
<jgart>like a package record, for example
<xelxebar>Apparently, its syntax looks like ($ record-name pat_1 ... pan_n), so yeah.
<jgart>xelxebar, have you tried using match on a package record?
<jgart>like vim or whatever
<Ribby>Why is the sig download taking a while on the terminal?
<xelxebar>lfam: Noticed this in dmesg! [318041.537171] guix[8660]: segfault at 10 ip 00007f0d2603c9b9 sp 00007ffc72e998d0 error 4 in[7f0d26026000+1b000]
<lfam>Definitely worth including in your report
<Ribby>What is reflashing the usb?
<xelxebar>jgart: Not personally. Only on custom records, but perhaps in my naivete, I don't see why package records would be different.
<jgart>yup, they're just records too
<jgart>custom records
<xelxebar>Ribby: Is that a philosophical question? Or are you just asking about `dd of=/dev/my-usb-device ...'?
<xelxebar>Or are you asking about the agent which is currently, actively reflashing "the usb"?
<xelxebar>Argh. For some strange reason, your comments keep breaking my brain.
<Ribby>Well, do I need to reflash a non-empty usb if I want to build guix on it?
<xelxebar>Okay, package-related question. Trying to switch to the new-style inputs, but my custom gexp in the list ends up just getting named "_", it looks like.
<xelxebar>Mixing styles doesn't seem to work. Is the new syntax just an all-or-nothing thing? Or did I miss something?
<xelxebar>Ribby: Not sure what you mean by "build guix on it." Do you have an iso or some custom image that you want to put on a USB drive?
<Ribby>Yes, but the usb is not a empty partition.
<xelxebar>Ribby: Drive partitions are different things than drives. Most likely, you will need to clobber the existing contents of the *entire drive*, not just the partition---i.e. overwrite /dev/sdx, not just /dev/sdx1.
<Ribby>Ok, that can be done, right?
<xelxebar>Yes, it's a common operation.
<Ribby>Ok, I'll figure it out and get back to here.
<robin>Ribby, literally cat guix-whatever.iso > /dev/$USB_DEVICE , but that will of course overwrite whatever's on the usb drive
<Ribby>Ok, sounds a bit like management
<raghavgururajan>Hello Guix!
<sneek>Welcome back raghavgururajan, you have 2 messages!
<sneek>raghavgururajan, jgart says: Yooooo guix homie are you coming to the guix docs meetup on Saturday?
<sneek>raghavgururajan, jgart says: Do you want to still write a blog post on bitmask together?
<raghavgururajan>sneek, botsnack
<robin>(and run 'sync' to make sure it's all written before removing it, or unmount it if it gets automounted, etc.)
<raghavgururajan>sneek, later tell jgart: Sure thing amigo! Lets do the blog post.
<sneek>Will do.
<jgart>sneek, later tell raghavgururajan: OK, let's do it. I gave sneek a zopiclone.
<sneek>jgart, you have 1 message!
<sneek>jgart, raghavgururajan says: Sure thing amigo! Lets do the blog post.
<robin>sneek, botsnack
***nf is now known as yoneda
<excalamus>I expected that when I used guix time-machine install with an old commit that it would replace the package in my current profile with whatever I installed. That doesn't seem to be the case. Honestly, I'm not sure what it did.
<apteryx>I came up with this ugly hack to help automate debugging programs wrapped by Guix shell scripts:
<apteryx>in case it may be of help to someone else
<lfam>excalamus: So, you tried doing something with the time-machine and it didn't have the expected result? Can you clarify by saying what you tried and what it appears to have done?
<robin>apteryx, ty! i've had to do that manually before, and surely will again sometime :) what do you name the script?
<excalamus>sneek, help
<excalamus>sneak, later ask lfam, I ran guix time-machine install as: and it produced: it appears to have installed. Maybe it wrote a guix/ directory to my pwd, too?
*v1dl00fyuq6f[m] sent a code block:
<v1dl00fyuq6f[m]>well <=3.5.0
<v1dl00fyuq6f[m]>GNUHacker help me
<v1dl00fyuq6f[m]>pretty pleeasee 👉️👈️
<robin>Ribby, continuing the conversation from #gnu, based on your screenshots i'd guess either the filesystem is corrupted and/or there's a hardware problem with your usb key
<Ribby>so the usb itself is unstable?
<Ribby>It's possible.
*v1dl00fyuq6f[m] hmph
*v1dl00fyuq6f[m] goes to ask on guix-help then
<robin>v1dl00fyuq6f[m], i don't think guix has python 3.5 specifically; if the program actually doesn't work with python 3.9 you might have to define packages for 3.5 (or alternatively, patch the program to support 3.9 if that's feasible)
<robin>v1dl00fyuq6f[m], actually, the c++ seems to indicate that 3.9 *is* a supported version (>= 3.5.0, not ==)
<robin>v1dl00fyuq6f[m], so python-3.9 or python-wrapper ought to work (the c++ checks for a python3 binary before python, so i suspect that the wrapper is unnecessary and you can just use, say, python-3 as an input, though that's just a guess)
<robin>Ribby, there are diagnostic tests you can run but honestly, i'd just try rewriting the iso image to the drive
<Ribby>Would I likely reflash/restore the usb drive from the corrupted image?
<robin>Ribby, also, the 1.3.0 installer is slightly buggy, so i'd recommend using the 'latest' image from
<Ribby>Are you seriously?
<Ribby>I thought it was stable.
<Ribby>I mean, no one's perfect, but you know.
<robin>the system is stable, but the installer is 'flaky' -- something about the 'GUI' installer and partitioning, iirc. 1.3.0 might work for you, it's just a suggestion as normally you'd be immediately upgrading to the latest version after installation anyway
<Ribby>immediately? sounds promising.
<Ribby>I wonder what is the incentive?
<Ribby>Isn't there a libreboot/libreroot bootloader in progress?
<Ribby>It's supposed to be its own stable independent bootloader. Like java being cross-platform in design.
<robin>Ribby, yes, there's both coreboot and libreboot, but they don't support recent PC motherboards afaik
<Ribby>So it's not updated to most/all computers.
<Ribby>Can they work on some 64 bit types?
<robin>talos raptor systems use a free bootloader, not sure if it's libreboot or something else:
<robin>some ARM-based systems also have free bootloaders, e.g. the mnt reform laptop (i don't know the bootloader's name; possibly u-boot?)
<robin>but with x86, currently the most that's being done is attempting to disable 'security processors' running nonfree code (intel IME, amd PSP) afaik
<Ribby>okay, so progress has been in lockdown for so time.
<robin>for x86/amd64, yes (again afaik, i don't follow bootloader development closely or anything)
<Ribby>It's kind of like the first step is nullified, but I get that priorities do happen.
<bricewge>Hello Guix
<robin>Ribby, if you're comfortable with the steps in 'manual installation' (mostly using command line tools for partitioning), 1.3.0 image is fine even if you get unlucky and hit the GUI-installer bug, as you can just install via command line
<robin>Ribby, you verified the signature on the ISO (IIRC), so the image file itself isn't corrupted, or verification would've failed
<robin>(or if you didn't verify, try that :))
<Ribby>I didn't get the public key, the servers/mirrors seems to time out for some reason. Is it the winter?
<robin>oh, hmm, i can download the x86_64 one ( without issues. maybe a temporary outage or something?
<Ribby>I didn't get any online instructions about TUI navigation and its many commands/parameters. However, it couldn't be too hard from the simple GUI.
<Ribby>Maybe, but it's just verification on one end. It's a different story on a DVD or USB.
<Ribby>It's like an inventory assessment after receiving the delivery. It's a tedious task, but a little assurance leads to a higher chance of success, step-by-step.
<Ribby>Once the real OS installation starts from the boot, it's technically the test within its assignment. I talk too much about bootloading.
<Ribby>What is the success rate of the 1.3.0 installer? On what conditions?
<lilyp>Ribby: the success rate of any installer is close to 100% if you use terminal and go for minimal setup first
<lilyp>once you have a minimal setup, you can bootstrap from there, which is much nicer in terms of error handling than reinstalling over and over
<Ribby>When you say minimal, you meant binary installation? Do I have a higher chance with a binary than system installation?
<jpoiret>no, more like installing only the bare minimum needed to boot into a terminal
<jpoiret>because sometimes if you install a whole desktop env directly you might get issues with graphics drivers and whatnot
<bricewge>jpoiret: I'm currently having a look at your patch for deluge
<bricewge>I don't understand this condition tho
<jpoiret>great, thanks! note that i don't use it but it was one of the reported bugs after the dec merge
<jpoiret>you mean the `filter` part?
<jpoiret>that's used to remove a reference to the build-time librsvg that's needed to convert svg files
<bricewge>Thank you, I just stumbled upon that bug myself
<jpoiret>otherwise it gets added to GI_TYPELIB_PATH in the program wrapper by a glib-or-gtk phase
<bricewge>No the `(or native-inputs inputs)` line
<jpoiret>oh, that's the standard way to get a native-input inside a phase
<jpoiret>when cross-compiling, native-inputs and inputs are both set to what you can imagine, but when not cross-compiling native-inputs is #f and everything is in inputs
<jpoiret>so this just gives you native-inputs when it's not #f, and inputs otherwise
<bricewge>Indeed, it's use in many packages, I never noticed before
<bricewge>Most of the time I forgot about cross-compiling... Thansk, I'll try it on master then
<v1dl00fyuq6f[m]><robin> "v1dl00fyuq6f, i don't think guix..." <- patch submitted already
<v1dl00fyuq6f[m]>to the program's upstream
<v1dl00fyuq6f[m]><robin> "v1dl00fyuq6f, so python-3.9 or..." <- what will `python-3` do?
<jpoiret>i'm not sure why that dance is needed though bricewge
<jpoiret>ie why couldn't native-inputs always be the native-inputs, but i've just been rolling with it :)
<nckx>Morning, Guix!
<v1dl00fyuq6f[m]>ehww the nacist is here i am gooneeee
<lilyp>imo, native-inputs should be set to (or native-inputs inputs) in the build-system code :P
<nckx>sneek: later tell v1dl00fyuq6f[m]: Behave.
<sneek>Will do.
<nckx>sneek: botsnack!
<lilyp>can we teach sneek to reply with a random smile emoji?
<nckx>Which we can then sell as NFTs.
<nckx>Good bye Guix o/
<robin>sneek, later tell v1dl00fyuq6f[m]: 'python-3' is the "current 3.x version" and 'python' is the "current major version", both are aliases for python-3.9 atm
<sneek>Got it.
<xelxebar>Cool! Programmatically building a package: (define (build-package pkg) (run-with-store (open-connection) (mlet* ((drv (package->derivation pkg))) (build (list (derivation-file-name drv))))))
<unmatched-paren>is skia in guix? i can't find it when i guix search, but according to {,ungoogled-}chromium uses it for graphics, which is in guix
<robin>unmatched-paren, it doesn't appear to be packaged standalone in guix. it's listed in both the qt and ungoogled-chromium packages amongst 'preserved-third-party-files', i.e. guix is using the bundled library for both packages (and also libreoffice is build with '--without-skia' with comment 'FIXME: Enable once the corresponding inputs are packaged.')
<fnstudio>hello, i wanted to pick your brain on something, if i look at it recommends to use $(guix build kmonad) to get the path to a file in /gnu/store/...-kmonad-0.4.1/...
<robin>unmatched-paren, but that suggests it isn't difficult to package, just that nobody's bothered yet
<fnstudio>now, as it happens, the expression is actually expanded to /gnu/store/...-kmonad-0.4.1-static/...
<fnstudio>and the relevant file is therefore not found
<fnstudio>while it's trivial to go past this, i wanted to suggest the kmonad people a documentation fix
<fnstudio>is there any "standard" recommended way to point to the relevant folder here, in other words avoiding the match with the static folder?
<robin>unmatched-paren, apparently skia has a very regular release schedule, except: "Note that 82 was abandoned by Chromium and 83 schedule moved in due to COVID-19 impact" which reminds me of :)
<unmatched-paren>robin: i was going to try to use it for a project, but i just noticed that skia is c++, not c, so i'll pass on packaging it myself :)
<atuin>Hi, seems taht pypi-url does not work for all the packages in mypi, is that a known issue?
<atuin>what's the workaround there, use real warehouse url for the source in the package definition?
<unmatched-paren>i'll just use cairo instead, which is already packaged
<robin>unmatched-paren, cairo doesn't have the benevolent influence of the big G hovering over it, so sounds like a good solution :)
<unmatched-paren>Cairo has another big G
<robin>fnstudio, the problem is that 'guix build' shows all the output paths, and there's no functionality (i think) for something like "guix build kmonad:out"
<robin>(if it's literally only listing the -static bath your guix is behaving very differently from mine)
<fnstudio>robin: no, i see, it makes sense, thanks - so i guess the best fix is to simply have the expanded path (maybe a pattern in lieu of the raw hash) in the docs?
<unmatched-paren> is interesting, but won't work on older devices, and it's pretty young too. but it and cairo have similar APIs... i wonder if i could have both a cairo backend (for old computers) and a vkvg backend (for performance); for now i guess it'll be simpler to focus on one
<fnstudio>robin: yes, it lists both
<unmatched-paren>and vkvg isn't in guix, of course
<fnstudio>robin: but that's enough for that particular bit of the kmonad docs to be broken
<robin>fnstudio, that would probably work, or use some heuristic to detect the "out" output (shortest line?)
<robin>specifying outputs in guix build feels a bit strange (as it will ofc build all outputs), i wonder if something like a "guix whereis" command might be handy that would let one specify an output, maybe version, etc., and exit(1) if it's not installed
<robin>or maybe i'm overthinking things and 'guix build' should just be extended a bit
<fnstudio>robin: with regard to the shortest line, hm yes, that'd work if we were in a script but i think it'd make the docs a bit more obscure
<fnstudio>robin: i like the idea of a "guix whereis" but i'm just a beginner here, so filed under "fwiw"
<fnstudio>robin: anyway, great, i think i can just suggest the longer form (with the expanded path) as a doc fix for now
*robin adds proposal to the TODO list
<fnstudio>robin: ty for helping with this!
<robin>fnstudio, oh right, you could just grep for kmonad-VERSION$, much simpler than using awk or something
<robin>fnstudio, np!
*robin makes a TODO for a 'guix whereis' proposal
*v1dl00fyuq6f[m] sent a code block:
<v1dl00fyuq6f[m]>i tried to add python and python-wrapper as dependencies, but that doesn't affect it
<sneek>Welcome back v1dl00fyuq6f[m], you have 2 messages!
<sneek>v1dl00fyuq6f[m], nckx says: Behave.
<sneek>v1dl00fyuq6f[m], robin says: 'python-3' is the "current 3.x version" and 'python' is the "current major version", both are aliases for python-3.9 atm
<v1dl00fyuq6f[m]>sneek: i know i have more accounts here i just have him on ignore and try to enjoy a better life :p
<robin>i guess skia might be worth packaging too, since libreoffice, at least, wants the standalone version (and we could probably remove one bundled library from chromium, given that releases are synced)
<v1dl00fyuq6f[m]>sneek: missed this one though, hmm O.o i see
<robin>v1dl00fyuq6f[m], you probably know this, but if upstream is slow about applying your patch or whatnot, guix can apply the patch itself (grep for search-patches in gnu/packages, and the actual diffs are in the aux-files directory there)
<robin>(maybe relevant since you're packaging an existing release rather than current git master, not that i know anything about qbittorrent's release schedule etc.)
<robin>unmatched-paren, whoa, vkvg looks pretty interesting if that perf graph is representative
<v1dl00fyuq6f[m]>as i had to put it in inputs not native-inputs
*v1dl00fyuq6f[m] feels dumb
<robin>unmatched-paren, makes me wonder if vulkan backends for cairo, font rendering libs, etc. might be worth implementing (though istr raph levien writing that using 3d for text rendering is quite tricky)
<unmatched-paren>hm, actually, vkvgj might not be that immature after all, one of the commits in the overview has a '2 years ago' timestamp
<unmatched-paren>github tries to make it as hard as possible to find commits for some reason...
<unmatched-paren>first commit was on 2021-12-28, not too young at all
<unmatched-paren>robin: yes, vulkan is supposed to be a lot faster, but i'd like to be able to support people with e.g. librebooted thinkpads that are way too old to have vulkan
<unmatched-paren>so cairo backend by default, vkvg if vulkan is detected as supported looks to be a good idea
<unmatched-paren>tbh, this feels like premature optimization for a simple toolkit-less 2d app :)
<unmatched-paren>(i'm trying to do it toolkit-less because Qt is C++ and reimplements a large portion of libcxx, and GTK depends on a truly repulsive OOP implementation with C macros, and i'd like to make the app keyboard-driven, which neither seem to have great support for...)
<robin>unmatched-paren, i started source-diving in gtk once for some reason and quickly gave up. i prefer gtk as a toolkit but the pseudo-OOP stuff, yikes
<unmatched-paren>to get around it, they created a pseudo-programming-language that's just c with a couple of sugars that get converted into their macros...
<florhizome[m]><unmatched-paren> "(i'm trying to do it toolkit-..." <- How about efl ;)
<unmatched-paren>good idea, i hadn't thought of that
<florhizome[m]>The number of toolkits is ever growing
<unmatched-paren>eh, i'll do it manually for the challenge :)
<v1dl00fyuq6f[m]>aaaAaAAaAA what's the difference in-between `inputs` and `native-inptus`
<robin>unmatched-paren, often the maximally fun way :)
<v1dl00fyuq6f[m]>i am confusing myself bcs i dunno which one provides runtime deps
<v1dl00fyuq6f[m]>bcs the manual doesn't have description for those attributes grr
<mfg>guix pull --news
<mfg>sry wrong window
<unmatched-paren>the difference only matters when cross compiling i think
<unmatched-paren>when you cross compile, the inputs are run inside the cross compilation environment, but not the native-inputs *i think*
<unmatched-paren>i've never cross compiled so i'm not sure
<unmatched-paren>so things like pkg-config can be native, since it doesn't matter where you run them, but any libraries that are linked in should not be native
<robin>native-inputs are for build-time dependencies, regular inputs are for runtime dependencies (dunno how that interacts with cross-compiling)
<unmatched-paren>s/where you run them/under what architecture you run them/
***irfus- is now known as irfus
<v1dl00fyuq6f[m]>why is python-wrapper in inputs not providing `python` executable for qbittorrent to provide search engine when it's source code is checking for the `python` executable
<v1dl00fyuq6f[m]>hmm mby version bug
<v1dl00fyuq6f[m]>yep bug in qbittorrent-4.2.0.
<v1dl00fyuq6f[m]>error: gpg failed to sign the data
<v1dl00fyuq6f[m]>fatal: failed to write commit object
<v1dl00fyuq6f[m]>i fix one problem
<v1dl00fyuq6f[m]>and other appears!!!
<robin>v1dl00fyuq6f[m], guix build -Kf will keep the failed build around, so you could check /tmp/guix-build-.../environment-variables (i think, the filename's obvious) and check that python/python3 is actually in $PATH at build time
<florhizome[m]><robin> "native-inputs are for build-time..." <- Native inputs are not kept around after build, propagated inputs are added to the profiles the package is installed in, as I understand it.
<v1dl00fyuq6f[m]>this is irelevant to the package i was trying to do GPG signature with git u.u
*v1dl00fyuq6f[m] sent a code block:
<v1dl00fyuq6f[m]>`export GPG_TTY=$(tty)` fixes it
<robin>florhizome[m], that sounds right, ty for clarifying
<florhizome[m]>buildtime/runtime doesn’t always translate, is what I understand (guix vets would make such points more clearly)
<florhizome[m]>f.e. If it’s just about a Library, it doesn‘t need to be propagated in guix as I would understand it.
*v1dl00fyuq6f[m] sent a code block:
<florhizome[m]>> <> ```... (full message at
<v1dl00fyuq6f[m]>works with `guix shell git git:send-email -- git send-email --to="" HEAD^`
<SeerLite[m]>I know why that is
<SeerLite[m]>Git is from system while sendmail is from usrr
<SeerLite[m]>You have to install both in the same profile
<SeerLite[m]>Had the same issue when installing it
<v1dl00fyuq6f[m]>nah i installed git in user
<SeerLite[m]>Wait really?
<SeerLite[m]>Then no idea
<SeerLite[m]>I installed both in my system config and it worked
<v1dl00fyuq6f[m]>we will call it the nckx curse and i will search the guix source code for `if(user = kreyren) { ruin_life() };` :p
<v1dl00fyuq6f[m]> merge.merge.meeerggeee~
<lilyp>I think it's a special form of projection when you claim the mods are ruining your life while basically ruining the life for everyone in the channel.
<v1dl00fyuq6f[m]>mhm i am special~
<v1dl00fyuq6f[m]>and not mods just him hmph
<v1dl00fyuq6f[m]>dammit it fails again
<jpoiret>i'd say it's more that he's the only one who was upfront about it
<v1dl00fyuq6f[m]>lily and u are upfront too and i don't hate her
<v1dl00fyuq6f[m]>i just don't like ppl that try to control my life :p
<jpoiret>did you try logging out and logging back in again
<jpoiret>no one's trying to control your life, they're just trying to keep this channel sane
<v1dl00fyuq6f[m]>jpoiret: mhm wiped cache and expected miracle, but it never came
<jpoiret>i'm not sure how git finds subcommands, but i'd say that logging out and logging back in to re-source all the env variables should be enough
<v1dl00fyuq6f[m]>seems that the cached build was build without the python dependency which influences the result even when it's not needed for build time apparently
<lilyp>You don't hate me, because I don't have the power to kickban you.
<v1dl00fyuq6f[m]>jpoiret: ah that nope didn't do that
<v1dl00fyuq6f[m]>lilyp: oh i though u have.. then i hate you :p
<jpoiret>there really are no build-time vs run-time dependencies
<jpoiret>only cross- versus host-
<jpoiret>i'm talking about Guix packages
<jpoiret>native-inputs and inputs really are cross- versus host-
<v1dl00fyuq6f[m]>like it using native-inputs when the dependency is not already installed on the system?
<v1dl00fyuq6f[m]>or it doing some sandbox and VM witchery to compile e.g. arm thing on x86_64 ?
<jpoiret>you can cross-compile without any virtualization
<jpoiret>compilers are able to run on an arch but produce code for another
<lilyp>no, native-inputs are compiled for the build machine and regular inputs for the host machine (which in most cases is also the target machine)
<jpoiret>well, not all of them
<lilyp>the meson manuals have a good explanation of cross-compilation setups
<v1dl00fyuq6f[m]>how do i ensure that python binary is available to the package then
<lilyp>if you find ours too confusing
<lilyp>you bake it in
<lilyp>this is the offending line
<v1dl00fyuq6f[m]>like hard-coding it? meeehhh
<lilyp>using python as input, you substitute* "python" with the actual path
<jpoiret>see for an example
<jpoiret>it's not hardcoding, you're rewriting the code to refer to the exact executable that it needs
<v1dl00fyuq6f[m]>lilyp: i already have python-wrapper in both inputs though
<v1dl00fyuq6f[m]>lilyp: and it still fails
<v1dl00fyuq6f[m]>oh i see
<jpoiret>python-wrapper in inputs doesn't do anything
<v1dl00fyuq6f[m]>ye O.o
<SeerLite[m]>jpoiret: Why is it in the package definition then? Was it added by mistake?
<robin>lilyp, but testPythonInstallation is, i'd imagine, checking $PATH, so mightn't a wrapper script for qbitorrent suffice?
<jpoiret>SeerLite[m]: oh, no, I mean that it just won't help with that, i wasn't clear
<lilyp>patching PATH is a last-ditch solution when everything else has been exhausted, I don't think it's needed here
<SeerLite[m]>Oh gotcha
<robin>fair enough
<jpoiret>the issue with patching PATH is that env vars are inherited by child processes
<lilyp>See emacs for a use-case that can't be hard-coded
<jpoiret>for some programs, that's okay, but it's always better to rewrite the invocations instead
<robin>probably i've just gotten too used to seeing wrappers used all over the place
<robin>(necessarily in some cases, of course)
<robin>v1dl00fyuq6f[m], so what i think is being suggested is that you retain a python 3 input, and then add a post-unpack phase to hardcode the path, something like:
<robin>(add-after 'unpack 'patch-python-path (lambda* (#:key inputs #:allow-other-keys) (substitute* "src/base/utils/foreignapps.cpp" (("\"python3\"") (string-append (assoc-ref inputs "python-3") "/bin/python3")))))
<robin>(perhaps with more context for the text around the substitution for clarity/maintainability)
<robin>(caveat: i haven't read up on the new non-alist-based inputs system so that might be unidiomatic or even broken now, with the assoc usage, but the new way is presumably similar)
***ashkitte1 is now known as ashkitten-irc
<singpolyma>robin: alist way still works fine
<robin>ah, the new way would be:
<robin>(add-after 'unpack 'patch-python-path (lambda* (#:key inputs #:allow-other-keys) (substitute* "src/base/utils/foreignapps.cpp" (("\"python3\"") (string-append "\"" (search-input-file inputs "/bin/python3") "\""))))))
<robin>...i think
<v1dl00fyuq6f[m]>robin: shouldn't i do something like `package.python` for it to expand in `/gnu/store/sdgjkasdjkhasdkjgh-python/bin/python` ?
<v1dl00fyuq6f[m]>(`package.python` taken from nixlang)
<v1dl00fyuq6f[m]>oh u r using substitute
<v1dl00fyuq6f[m]>wait no u ain't
<v1dl00fyuq6f[m]>just substituting with /bin/python3
<v1dl00fyuq6f[m]>dunno what `search-input-file` does
<v1dl00fyuq6f[m]>... well i know what it does, but don't understand the context
<robin>it's new, it searches the inputs for the specified file and returns the path, or raises an error if not found (an improvement over the old system)
<v1dl00fyuq6f[m]>so what the code does it replaces the python with /gnu/store/sjkdhkahdskha-python/bin/python right?
<robin>v1dl00fyuq6f[m], right
<lilyp>or python3 :P
<robin>idk if there are other parts of qbittorrent that would have to be tweaked, but that should fix the version check at least
<v1dl00fyuq6f[m]>kinda hate the solution as it's depending on declaration in with upstream being unaware and lacking QA to know that changes in that file will break guix
<v1dl00fyuq6f[m]>hmm i should probably submit a check that looks for /gnu/store directory on the upstream to find the python thing
<v1dl00fyuq6f[m]>or is that insane?
<v1dl00fyuq6f[m]>is there a way to define package to use local git directory? i want to do some testing with the source code
<robin>v1dl00fyuq6f[m], i don't understand what use a check would have, and also guix can be run on foreign distros so it could confuse a non-guix qbitorrent
<v1dl00fyuq6f[m]>robin: i was thinking something like:
<v1dl00fyuq6f[m]>If ran on guix system -> check that python is available through guix-way
<v1dl00fyuq6f[m]>dunno how would i imlement this though..
<v1dl00fyuq6f[m]>meh too much effort let me just tag it
<robin>v1dl00fyuq6f[m], if on guix system, qbitorrent would be installed via the guix package and python would always be available to it
<v1dl00fyuq6f[m]>How is it always available to it?
<robin>v1dl00fyuq6f[m], substituting just "python3" is indeed a bit fragile, which is why i suggested possibly replacing the whole testPythonInstallation call for maintainability
<v1dl00fyuq6f[m]>e.g. run `guix shell qbittorrent -- qbittorrent` and then do `view -> search engine` and observe the issue that i am trying to address
<robin>because one would install the guix package with python 3 as an input
<v1dl00fyuq6f[m]>robin: i tried that but it's not available to it
<robin>i mean if the finding-the-right-python problem were solved, not the current situation where it fails if the right python's not in $PATH
<jpoiret>i mean, of course a downstream patch would depend on upstream not changing the file too much
<v1dl00fyuq6f[m]>ehh the checking on upsream expects python in $PATH though?
<jpoiret>but in case it changes, it shouldn't be too hard to change the patch
<lilyp>does it really?
<v1dl00fyuq6f[m]>lilyp: unless i am reading the source code wrong
<v1dl00fyuq6f[m]>which is possible bcs CPP is giving me headache such a stupid lang omg
<robin>if testPythonInstallation does what i think it does (QProcess proc; proc.start(exeName ...)) i can't imagine it not checking $PATH
<jpoiret>it uses proc.start, so i'm pretty sure it uses PATH
<lilyp>I can't imagine it checking PATH unconditionally
<v1dl00fyuq6f[m]>so `(inputs .. python` is expected to provide the executable in $PATH?
<jpoiret>no, it'll just provide it in the build env
<v1dl00fyuq6f[m]>so useless for the solution as this is runtime-check right
<lilyp>checking path should only be done for command names, not absolute paths
<lilyp>and since you're baking in an absolute path…
<jpoiret>i don't see what the issue is with baking absolute paths in
<v1dl00fyuq6f[m]>lilyp: so do u have a better way to make the package to check `python` from the $PATH on runtime?
<jpoiret>it's the necessary tradeoff that guix has to do
*v1dl00fyuq6f[m] hates hardcoding absolute paths
<lilyp>just do it, lol
<jpoiret>Guix itself does rely on having hardcoded absolute paths
<v1dl00fyuq6f[m]>jpoiret: means that someone else has to change the file in the future and experience failure in the wild though
<jpoiret>that's how it knows which packages are in the closure for example
<robin>lilyp, oh, maybe it doesn't check $PATH in the case of absolute paths or something. but it's being called with just "python3", "python" etc. as first argument which is what i was referring to
<jpoiret>v1dl00fyuq6f[m]: yes, if upstream does change that file a lot in the future, someone will have to fix it. but that shouldn't be too hard
<jpoiret>distros patch upstream programs a bunch
<lilyp>robin, in that case, yeah, it checks PATH
<v1dl00fyuq6f[m]>jpoiret: i prefer to make more robust code tbh the longer it works the more hapier i am
<jpoiret>well, it's robust: the patch works for this guix version :)
<robin>v1dl00fyuq6f[m], it means that a package maintainer might have to update the definition in the future, shouldn't ever affect end users
<v1dl00fyuq6f[m]>i guess
<v1dl00fyuq6f[m]>i tagged it with suggestion for a more robust improvement at least then
<jpoiret>the more robust approach would be to add a pkg-config-like system for executables
<jpoiret>but alas
<jpoiret>if anyone's able to move the status-quo on the “yeah executables are in PATH, that's it”, go for it :)
<v1dl00fyuq6f[m]>So all GNU's fault then :p
<v1dl00fyuq6f[m]>> Scheme Syntax: substitute* file ((regexp match-var…) body…) …
<v1dl00fyuq6f[m]>What regex is it using?
<v1dl00fyuq6f[m]>hmm seems to be PCRE
*v1dl00fyuq6f[m] is trying to do `if\s+\(testPythonInstallation\(\"(python3)\",\s+pyInfo\)\)\s+return\s+pyInfo;` and failing to figure out how to change the first group
<robin>v1dl00fyuq6f[m], not quite PCRE, POSIX ERE if i remember the name correctly, but similar syntax yes
<v1dl00fyuq6f[m]>oh so without \s
<v1dl00fyuq6f[m]>how do i substitute the groups though
<jpoiret>i'd just substitute "\"python3\"" personally
<robin>v1dl00fyuq6f[m], i think \(, \| etc. is just ( and | with EREs, though you could grep the source to check. as for submatches...
<robin>that's why the regexp is in parens, you can add MATCH-VARs bound to the matched text for use in the body
<robin>see (info "(guix) Build Utilities") for details
<v1dl00fyuq6f[m]>match vars?
<robin>variables containing the text matched by (...) groups
<v1dl00fyuq6f[m]>robin: oh i am already looking at that just odn't understand the text
<robin>oh nm, i misread your regexps (getting tired), you're using backslashes correctly
*v1dl00fyuq6f[m] sent a code block:
<v1dl00fyuq6f[m]>e.g. `all` storing `[a-z]+` ?
<Ribby>Hey, After a bit of research, plus a long time idling. Success! My usb is reformated with a working enough os boot!
<Ribby>I decided to combine the stress code of both guix and netbsd (mentioned in #gnu). It made my usb go boop once in a while. It's like the computers of the great old days!
<gnoo>how do you enable tab completion on pass(1) on guix?
<Ribby>Got a question, what is the best desktop interface environment/design?
*v1dl00fyuq6f[m] sent a code block:
<v1dl00fyuq6f[m]>so like this right
<Ribby>I hope that tab question isn't directed at me for answering.
<Ribby>sudo dd if=guix-system-install-1.3.0.i386-linux.iso of=/dev/sdb bs=1M
<Ribby>cited references:
<robin>v1dl00fyuq6f[m], i think the first MATCH-VAR is simply all the matched text, so with your regexp, the substitute* subclause would be something like (REGEXP all python-3-path), and then (string-append "if (testPythonInstallation(\"" (search-file-inputs inputs "/bin/python3") "\", pyinfo)) [...]") for the replacement
<Zelphir>How do you make that "<person> sent a code block" thing?
<robin>v1dl00fyuq6f[m], also, i don't *think* substitute* does multiline regexps; personally i'd just substitute the function call
<gnoo>Zelphir: that's a matrix thing, you can just use a pastebin and then say /me sent a code block <link> ;-)
<robin>Zelphir, that's a matrix thing, i believe, IRC users tend to use (and paste the link manually)
<Zelphir>:D two answers with the same prefix
<robin>Ribby, \o/
<Ribby>Yes, but maybe I procrastinate a bit too much. It could have been more efficient.
<robin>Ribby, re: DEs, it's a matter of personal preference of course, but gnome seems to be basically the default (i use gnome on x11). i think some of the 'lightweight' DEs are packaged (xfce?), kde is not last time i checked
<Guest72>So, any one can help me sort out the installation on an lvm. I get an error while booting. not sure anymore: error in ice-9/boot-9.scm. My config:
<robin>Guest72, if vg0-store happens to be for /gnu/store, that should be in file-systems marked as needed-for-boot, i think
<robin>just guessing; 'error in boot-9.scm' could be from almost anything, some context for the error would be helpful
<Ribby>Oh, nvm, the boop is from my computer.
<Guest72>I'm quite sure it's something with the lvm. Modules/packages missing?
<Guest72>do I need ice-9 declared in the config?
<Ribby>The installation surely has plenty of download.
<v1dl00fyuq6f[m]>BWAHAHAHA i figured out the substitute*
<v1dl00fyuq6f[m]><robin> "v1dl00fyuq6f, i think the..." <- oh
<v1dl00fyuq6f[m]>i don't understand the substitute* again
<v1dl00fyuq6f[m]>oh nwm i do
<v1dl00fyuq6f[m]>i think
<v1dl00fyuq6f[m]>seems to work(TM)
<robin>Guest72, you shouldn't typically need to import ice-9 modules in config.scm
<jpoiret>Guest72: can you add (dependencies mapped-devices) to the root filesystem definition?
<Guest72>i've got this:             (ice-9 optargs)
<v1dl00fyuq6f[m]>jpoiret: isn't that only the case if the dependency is not used?
<jpoiret>Guest72: also, ice-9 boot-9 is just guile stuff, nothing related to the actual computer booting process
<jpoiret>v1dl00fyuq6f[m]: wdym?
<jpoiret>that filesystem needs lvm to assemble to volume, right?
<v1dl00fyuq6f[m]>jpoiret: like guix has a hard imports for some things no?
<robin>oh good catch jpoiret, that could be the issue
<Guest72>Right. but configuratinon/system init executes without an error
<jpoiret>yes, but forgetting the deps won't produce an error at reconfigure time
<jpoiret>but then early userspace might just forget to assemble the proper things before mounting root
<Guest72>This are my first steps in this. I will try to include the declaration.
<excalamus>good morning, Guix!
<v1dl00fyuq6f[m]>excalamus: mhm
<Guest72>Who knows how Ian Murdoch died?
<v1dl00fyuq6f[m]>same as epstein by the government
<Guest72>Just had a quick look. Sun, Oracle... dead
<v1dl00fyuq6f[m]>is there a way to stop at phase to see what the phase did
<v1dl00fyuq6f[m]>my substitution is not working and i can't find the files to see what it did
<v1dl00fyuq6f[m]>oh i think i know what's wrong
<SeerLite[m]>Maybe a `(error)` call at the end of the phase so it stops there
<v1dl00fyuq6f[m]>oh oke
<efraim>gah, more time needed to figure out why 94c70b5440334c7c844e20350351bd5565aff137 works on riscv64-linux and not on x86_64-linux
<KarlJoad>Has somebody manually used certbot to generate SSL certificates for their site hosted on Guix? I keep running into an error with challenge response.
<v1dl00fyuq6f[m]>> /note: keeping build directory `/tmp/guix-build-qbittorrent-4.4.0.drv-1'
<v1dl00fyuq6f[m]>*it's empty*
<Digit>looking forward to guix days, "February 20-21: Guix Days!"
<SeerLite[m]>> <> > /note: keeping build directory `/tmp/guix-build-qbittorrent-4.4.0.drv-1'
<SeerLite[m]>> *it's empty*
<SeerLite[m]>You're adding the substitute* after the unpack phase right?
<Ribby>I'm testing the time as the guix installs. It has been over an hour. Passed the downloads and the /mnt copying. It's doing that daemon stalling again. I could wait for another hour. Tons of downloads!
<Andrew_>For guix users in China or other parts of Asia: I found a mirror at, works pretty fast from here. It seems that the main mirrors are problematic (10 KB/s), might even be of use to people outside of Asia. (Shanghai JT University it seeems to be)
<Andrew_>Okay, time to wipe out my entire system.
<Andrew_>How do I change the substitute mirror before installation? I want the installation to be 1MB/s, not 10KB/s
<xelxebar>Andrew_: --substitute-urls='...'?
<Andrew_>I'm pretty new, I should press F1 to change params before install?
<xelxebar>After doing `guix archive --authenticate` on the keys, of course.
<xelxebar>Andrew_: Oh. Sorry. I've never used the graphical install :/
<Andrew_>Nice, I'm actually looking for a manual install guide
<Andrew_>(I come from Parabola, more used to that)
<xelxebar>Are you on the live iso?
<dcunit3d>Andrew_: look at the substitute authentication section. you have to add the channels and ensure that config.scm is aware of them. then download and authorize the key. then when your run `guix reconfigure`, pass the --substitute-urls
<xelxebar>If you Ctrl+Alt+F2, that should switch you to console 2, which has a manual installation guide, IIRC.
<Andrew_>Okay, got it
<Andrew_>Being able to edit the substitute URL before install would be really handy for newbs
<Andrew_>And, I like the fact that the guide is AVAIL offline right in the iso :D
<Andrew_>*connects the ethernet cable*
<dcunit3d>if you add the key, authorize then set it up in vtty2, will the substitutes be available in the curses installation GUI?
<Andrew_>I assume not
<Andrew_>not detecting my ethernet, fun
<dcunit3d>Guix updates some things on disk. but if the `--substitute-urls` flag is necessary, then the curses install may not call things correctly.
<Andrew_>WiFi won't work either. It's definitely free, it worked w/ parabola
<dcunit3d>the guix/libreboot page has some info on getting wifi up
<Andrew_>Yeah. Not a problem right now, got eth0 working.
<Andrew_>... it makes me use nano insteadd of emacs or vi to edit the config
<dcunit3d>what are you using for eth0 config?
<Andrew_>err, eno0; NetworkManager
<dcunit3d>i had some trouble getting ethernet to work without DHCP, but i was on a different usb image
<dcunit3d>i don't think nmcli was available. i used ip tools
<Andrew_>aw, messed up the partitions, fun
<Andrew_>partprobe doesn;t wanna work, reboot.
<dcunit3d>when you run guix system init, you may need to give it --substitute-urls
<Andrew_>Noted, thank you :D
<Andrew_>... what kind of name is the 'herd' command on Linux? This is Linux lol
<v1dl00fyuq6f[m]>that damned thing is lieing to me
<Andrew_>Well, I wouldn't call this a real manual installation. I'm still writing to a specific configuration (config.scm).
<Andrew_>I want both BIOS and EFI boot, probably just gonna grub-install afterwrads
<jpoiret>why though?
<jpoiret>unless it's for a live USB, is there any reason to use legacy boot?
<Andrew_>I swap the hard drive among multiple computers
<jpoiret>i don't think grub-installing will be sufficient for bios
<Andrew_>then... remaking the grub config?
<jpoiret>maybe using legacy grub in the guix config, and grub-installing the efi manually could work
<Andrew_>ill do that after the first reboot, I don't want to mess up too much
<jpoiret>the issue is that the bootloader is pretty tied to system config
<jpoiret>basically, guix installs the bootloader itself because 1) the kernel and initrd are in the store, they're never moved to eg /boot 2) it wants to update the list of system generations available from grub whenever there's a new one
<lilyp>Andrew_: on other Linuxen, they call it systemctl
<jpoiret>it controls GNU Shepherd, the init system
<Andrew_>lilyp: No such thing on Parabola OpenRC :D
<Andrew_>I noticed, thanks
<Andrew_>filesystem errors again, yay
<Andrew_>I'm just too stupid [tm]
<Andrew_>what- it's still 10 kb/s?
<jpoiret>those routing issues are pretty bad
<Andrew_>Even while using a mirror by a local university
<Andrew_>tiff-4.2.0.tar.gz stuff
<Guest72>Anyone have root on lvm? Installation finished without errors, but when booting i get: ...logical volumes found... Found vol group, and ice-9/boot-9.scm:1669:16: In procedure raise-exception: pre mount action failed
<Andrew_>Root on LVM => problems
<Guest72>I'm a living proof
<Andrew>lol true
<dcunit3d>it will continue pulling substitutes from other servers. i'm not 100% sure on how it works, but the order in which you include them matters. also, the server's key needs to be in the ACL
<Guest72>How can I look in to it form the early guile?
<dcunit3d>is it pulling from the right mirror and still getting 10kb/s?
<Andrew>dcunit3d: No idea
<Ribby>So far, it's working but I guess my longer ethernet cable isn't helping. Some of the desktop environments can influence wired connections. Some of them are just bad interface design.
<Andrew>It gave me 1000 lines sayin 'updating subs from ... right mirror ...'
<Andrew>Is it safe to ^C ata this point, where it's downloading cunit?
<dcunit3d>Andrew i did that several times, but that's up to you
<Andrew>k, ig it's not too big of a deal
<dcunit3d>i was okay with losing the data and starting over though.
***Andrew_ is now known as AndrewYu
<Andrew>What- Some sort of wsmoused going on there I assume
<jgart>sneek, later tell apteryx: cool script! can you describe one example context in which you've used that script. I'm just trying to understand how I can start using it in my own workflow.
<sneek>Got it.
<Ribby>My long extension ethernet cable, is the goldxp jditechnologies?
<Ribby>50 feet.
<apteryx>jgart: anytime a C/C++ binary is wrapped with wrap-program (a shell script which ends with `exec ... "/gnu/store/.../.binary-real"
<sneek>Welcome back apteryx, you have 1 message!
<sneek>apteryx, jgart says: cool script! can you describe one example context in which you've used that script. I'm just trying to understand how I can start using it in my own workflow.
<Andrew>Yay! Mirrors working.
<Andrew>500KiB/s, enough for me
<Andrew>Gets to 3MiB/s for large ones
<apteryx>these scripts are a bit of a pain to work with GDB as they cannot be invoked directly (it wants an ELF binary) and if you invoke it through sh, the the automatic debug symbol loading doesn't happen (if debug symbols are available).
<Andrew>Apparantly, it still wants to download a few things from
<apteryx>I think it was suggesed to use 'gdb --args sh /path/to/the/the-wrapper-script'; this works but it prevents correct loading of debug symbols. Compare for example: guix shell -E XDG --pure jami jami:debug gdb bash -- gdb --args bash jami-qt --> (No debugging symbols found in bash)
<jgart>apteryx, thanks! what's one scenario of what you have done while in gdb to debug a guix package that you're working on? See the backtrace? step through the program evaluating functions? inspecting local variables?
<jgart>In other words, is there something that you find yourself doing very frequently when using gdb to debug guix packages?
<apteryx>jgart: typically just seeing the backtrace as I'm not much of a C/C++ dev
<apteryx>here's the script in action: ./pre-inst-env guix shell -E XDG --pure jami jami:debug gdb coreutils bash which grep -- /home/maxim/.local/bin/run-gdb jami-qt --> Reading symbols from /gnu/store/j10v84dahng52zfxmrzyw31wd90fq35d-jami-20211223.2.37be4c3/bin/.jami-qt-real...\n Reading symbols from
<apteryx>GDB sets GDB_DEBUG_FILE_DIRECTORY when in a profile (pointing to $GUIX_ENVIRONMENT/lib/debug), and with some glue in your ~/.gdbinit that essentially does "set debug-file-directory $GDB_DEBUG_FILE_DIRECTORY", it works rather well. That glue in gdbinit is installed out of the box when using Guix System
<apteryx>that's explained in "info '(guix) Separate Debug Info'" for the reference
<apteryx>with the snippet that can be installed manually on non Guix System distributions, as long as GDB was built with Guile support there.
<apteryx>(or just use GDB from Guix :-))
<Andrew>The info pages say in node 3.7: ... and join us on '#guix' on the Freenode IRC network (BUG)
*Andrew reboots
<j`ey>there was a message, it said to run 'guix pull', followed by something else, but it scrolled by too quickly, and I can't see what it was
<j`ey>to update everything
<apteryx>sneek: later tell Andrew not in the latest manual (it mentions Libera_Chat there)
<sneek>Will do.
<Andrew>lol I'm right here
<sneek>Welcome back Andrew, you have 1 message!
<sneek>Andrew, apteryx says: not in the latest manual (it mentions Libera_Chat there)
<Andrew>Noted, thanks
<Andrew>it;s in the latest ISO though
<ngz>j`ey: guix upgrade ?
<apteryx>Andrew: yes, there's not much we can do about past release. We're working on 1.4.0 due soon (TM).
<Andrew>lol great
<apteryx>or if you 'guix pull' you'll get the new manual
<apteryx>also available online at
<Andrew>noticed, thanks
<nckx>Hullo (again) Guix.
<nckx>v1dl00fyuq6f[m]: Sending me threatening knife emojis in PM is not a great start to the new year. Go down the same road as last year & you'll end up in the same place.
<apteryx>robin: not a very good name, but I placed it in ~/.local/bin/run-gdb to keep it short to type ;-)
<apteryx>nckx: o/
<jgart>apteryx, thanks for sharing! I'll try to find a scenario for me to use it. I've been meaning to start using gdb to debug C/C++ guix packages I'm working on.
<jgart>apteryx, Are you familiar with the recent API for guix build-systems? Would you be able to give a quick glance at this composer-build-system and see if there is anything deprecated or funny (wrong):
<jgart>Or anyone else that might want to review it on irc
<Ribby>I just say that mate, openbox, and xcfe, are the environments that could hold up a (long) ethernet connection.
<Ribby>will note this.
<jgart>Mind the differing module structure from upstream, I'll make it conform to upstream in the next commit(s). I was just hacking around with trying a different one/experimenting
<jgart>The composer-build-system is from this issue:
<ss2>hello, I'm trying to understand this post a bit better: Here Maxim suggests that I use search-input-directory. But I don't understand their reasoning that I am hard coding paths.
<lfam>ss2: I can help
<nckx>ss2: You're hard coding the ‘3.9’ version, which won't be correct when Python updates (which happens regularly).
<lfam>nckx can help too
<ss2>I thought about that version number, okay.
*nckx was already typing, it happens.
<j`ey>ngz: thanks
<lfam>ss2: You can also use something like (package-version (this-package-inputs python)) <-- untested
<j`ey>ngz: seems like guix pull itself is already taking a long time!
<nckx>lfam: Multiple people helping sounds like a luxury, not a bug 😉
<Andrew>Yay, I think I'm doing everything right
<Andrew>Mirror problems these days
<ss2>I'd need some attention multiplexing. ;)
*Andrew gets freaking 15MiB/s from an local mirror
<ss2>I'm gonna be a afk for a short while, please keep writing. I'll be back soon.
<ngz> j`ey: "guix pull" can be fast if you authorized substitutes and those are available. Otherwise, it can take some minutes, indeed.
<j`ey>ngz: some minutes is like 20mins or so
<j`ey>it's in a vm, so thats not helping
<nckx>Andrew: The Chinese one?
<ngz>j`ey: My hardware is a bit old, but if I had to make a guess, I'd say it takes around 5-7 minutes here.
<j`ey>ngz: good to know, it's been at 'Computing Guix derivation for..' for a bit now
<lfam>j`ey: Is your VM taking advantage of hardware acceleration? Like, if you are using QEMU, did you pass '-enable-kvm' and ensure that your user is able to use KVM?
<j`ey>lfam: it's virtualbox on macos, Im pretty sure it's hw virtualised, but its at least moving again
<lfam>Oh, okay
<j`ey>downloading some packagges
<Ribby>Man, it was a heavy sit-in. Still got just a bit of tinkering to do.
<shtwzrd[m]>How long does it normally take for a reply to to actually show up on ?
<shtwzrd[m]>I've only used git send-email a few times and it's always so far in-between that I have to look up how to do it again. I was worried I had somehow done it wrong, because it took 6 hours or so before it showed up.
<nckx>shtwzrd[m]: It really depends™. It can take minutes or hours. I'd say hours is rare but your experience may differ.
<nckx>All I can say is you're not stuck in moderation.
<nckx>(‘Yet’ or ‘anymore’ I can't say either.)
<j`ey>so what exactly does guix pull do? seems to be what I expected guix update to do?
<j`ey>or does update actually 'switch over' to the new versions?
<nckx>j`ey: It fetches the latest version of Guix (= package manager + package definitions) and builds it, so when you next run ‘guix whatever’ it will operate on the newest available set of packages.
<nckx>Assuming ‘update’ = ‘guix upgrade’: ‘guix upgrade’ installs the newest version of any matching package you previously had installed.
<j`ey>what does 'builds it' mean there?
<j`ey>what is the 'it'
<shtwzrd[m]>What's the etiquette around CC'ing others in a reply to debbugs? If I'm responding to a change request from a maintainer or answering a question, should I CC them or is that considered rude? I didn't do it in this case because I was worried debbugs would mail them anyway and they'd get two mails instead of one.
<shtwzrd[m]>But if there can be 6 hours of delay between messages a very simple exchange is suddenly a several day ordeal and if it were me on the other end, I'd rather get two mails than one that was so delayed.
<nckx>j`ey: The latest version of Guix.
<nckx>As defined in the brackets.
<j`ey>nckx: but it doesn't build the all the package definitions? just the ones related to guix?
<nckx>shtwzrd[m]: I consider CC'ing people (as in ‘reply all’) polite… 🤷
<nckx>j`ey: It compiles all package definitions. It doesn't build all packages.
<j`ey>nckx: ah, I didn't realise that was separate things
<nckx>Definitions = the Guile code that describes each package, this is what is built when you ‘guix pull’ and why it takes too long for anyone's comfort.
***ChanServ sets mode: +o nckx
<j`ey>i assumed that would have happened at guix install time
<shtwzrd[m]>nckx: Thanks :) I think I'll do that next time.
<nckx>I've never heard anyone complain!
<j`ey>I think this VM is underpowered, or my host machine is, it's stuck at 0% of building guix-packages.drv
<nckx>Don't underestimate the suck. It takes ~10 minutes on an i7-3615QE.
<nckx>Not the newest CPU, I'll admit.
<j`ey>nckx: for the entire `guix pull`?
<nckx>To build (compile) all Scheme modules locally without substitutes.
<j`ey>hm, maybe I'll wait until I can try on a beefier machine or something
*nckx blushes at their 9-y.o. ThinkPad — ‘you're beefy!’
***ChanServ sets mode: -o nckx
<kete>not mad but installed a Guix system with Openbox, which is just a black screen with a pointer that can't open any of its right-click-listed applications, not even a terminal. WiFi doesn't seem to have persisted, so I guess I'll try to set that back up and install LXQt.
***ChanServ sets mode: +o nckx[m]
<florhizome[m]><kete> "not mad but installed a Guix..." <- That was the same for me, when I tried opening up lxqt/openbox
<kete>Hmm, lxqt wasn't an option, so I went with openbox to install the rest later.
<florhizome[m]>just saying, might be that openbox doesn’t work with lxqt, too.
<florhizome[m]>You could set up a different wem though, probably
<florhizome[m]>i have kwinft packaged locally here, which works :D
<florhizome[m]>Oh ofc that means you don’t really need lxqt
<kete>oh, I thought that's what lxqt used. website says "Window Manager agnostic"
<florhizome[m]>guix ships lxqt with openbox by default, but it should work with others, yes
<florhizome[m]>I just hope that it does not start openbox by default until you set something different
<kete>kwinft was news to me
<kete>oh, it looks like that's how openbox starts until you change the background and install applications.
***ChanServ sets mode: -o nckx[m]
<kete>I guess I just need to set up wifi and install some applications.
<SeerLite[m]>Woah why does this channel look awesome from Matrix now
<SeerLite[m]>Thank you nckx
<nckx>The ‘official’ (IRC) channel looked dodgier than the unofficial (native) one; can't have that.
<lilyp>Speaking about unofficial IRCs, should we really advertise third-party wikis and IRCs on libreplanet?
<excalamus>I would say no. I had added the system crafters because the other one was already on there. I figured if the one was there, it should at least be balanced out
<nckx>I vote no as well.
<nckx>For the chat at least. I'm less sure about the wikis.
<nckx>Since there isn't an official that-kind-of-wiki wiki.
<excalamus>I find the whole wiki thing confusing. Some people want it, some hate them, and then the wiki that's there is, frankly, hard to update (in terms of mark up language)
<nckx>My response to ‘you must host a wiki’ was always ‘be the change you wish to see in the world (and don't expect the project to maintain one for you)’. It's a bit unfair to then not even hint at their existence IMO.
<nckx>I added the disclaimer that's there now as a compromise, but I'm glad this is being discussed.
<excalamus>jgart had talked about possibly removing the wiki link from the Guix homepage. I think that's a reasonable idea, since it seems mainly for admin type stuff.
<excalamus>it's also listed on the main page as a place to get help, which it's not (officially, AFAIK)
<nckx>I didn't realise it was on the home page TBH.
<nckx>Which main page excalamus?
<nckx>Ah, it's under ‘Help’, you mean?
<nckx>Yes that is not good.
<lilyp>The disclaimer is a welcome addition at least.
<nckx>Mind you, the wishlist is quite regularly used.
<excalamus>it's in the help menu and here:
<nckx>If it weren't for that list I'd be less ambivalent.
<excalamus>how is the wish list used?
<lilyp>I just worry that certain people might even void our "no warranty" disclaimer.
<lilyp>excalamus: just add a package to it and some person might read it and think "yeah, I can package a whole bunch of Javascript easily"
<lilyp>tbf it's not always that bad, but there's differences in how difficult things on the list are to package
<nckx>excalamus: I mean used as in people seem to find there way to it and add stuff, and occasionally someone removes something that was packaged. There is no official drive to package things on the wish list (that kind of motivation is alien to me and, I believe, most volunteers) AFAIK.
<nckx>I think I've packaged one wishlisted thing because it sounded cool & new *to me*, which seems the best-case scenario.
<excalamus>okay, I was curious if it was a list someone added to based on the mailing list or something.
<nckx>Some helpful individual might choose to do so.
<nckx>But there's no policy of any kind AFAIK.
<lilyp>Remind me that I need to update ppsspp, I'm a busy girl lately
<excalamus>looks like a handful of people edit it, and fairly regularly
<jgart>If someone would like to send a patch to remove the LibrePlanet wiki from the Guix website feel free to. I might not be able to get to it for a week.
<lilyp>nah, it's a distinct entity from the ML entirely (and that's good)
<jgart>Unless people prefer to keep it
<excalamus>ha-ha, yes yeah the mailing list didn't seem to like it much
<jgart>just something that was brought up in the Documentation Meetup (by roptat?)
<nckx>jgart: Do you know when/by whom it was added? Yes I could check the history, but asking you first is less work :)
<jgart>can't remember who exactly now
<nckx>It was new to me, literally have no idea if it's been there for years or days. Whelp.
<nckx>Apr 1.
<jgart>nckx, re: who added it: hmmm, don't know. didn't git blame that far
<excalamus>I was just going to comment on that, lol
<lilyp>April 1st is a normal day in other parts of the world.
<jgart>ah ok, there you go: 47555
<nckx>jgart: Have you ever based your workshops on the wishlist?
<nckx>I think people are just going to groan if I start yet another wiki discussion on the ML.
*nckx saves draft for now.
<excalamus>what were you thinking of bringing up?
<excalamus>I'm all caught up with WW2 week by week. Any suggestions for nerdy, but not full on lecture, videos. I'm a fan of things that are long running.
***yoneda is now known as nf
<Ribby>I can't believe I am still up. I got documentation to do. So far, installation redundancy stress tests is hold out pretty well. Man, I think I should get another usb as a backup. What do you guys think?
*jonsger does not understand why the latest 3 commits from nckx on master trigger so many rebuilds...
<jonsger>`guix refresh --list-dependent` says 1 or 0 for them
<Ribby>I think I was years younger when I tampered with some Linux brands as well as GNU. I think I got deja vu! At least it wasn't for naught. Actually, I should be grateful that such things exists!
<nckx>jonsger: It's the usual ‘hidden’ inheritance through hplip-minimal.
<nckx>Thanks for the heads up.
<jonsger>ah, "2412 abhängige Pakete " sounds bad...
<nckx>I wish ‘guix refresh’ were cleverer.
<nckx>(There's no hope for me.)
<jonsger>or we inherit hplip from hplip-minimal (the other way round)
<jgart>nckx, I've used various things. I used to have a kanban for tasks that I was using for the first meetups on a free instance of taiga provided by disroot: I've also contributed to the LibrePlanet wiki. I might have used the LibrePlanet wiki once in one of the meetups.
<nckx>That would be more conventional, jonsger. Good point.
<nckx>I don't see any drawbacks to doing so (—on core-updates! :)
<lfam>Does anybody know if Guix's HTTP proxy support is working? Can we close this old bug? <>
<nckx>jgart: OK, thanks.
<nckx>It is quite satisfying to see ci.guix finally chomp through rebuilds like the kilocore monster it is.
<nckx>Bit less so for aarch64 unfortunately.
<nckx>j`ey: (@ me? To?)
<j`ey>nckx: at you, yes1
<nckx>Needs moar DHTML live animation.
<j`ey>the ci does cross compilation? (didnt sound like it with the aarch64 comment)
<nckx>j`ey: No. It used to perform emulated ‘native’ builds (--system=foo; distinct from --target=foo cross-compilation in Guix) but this was disabled because (1) emulation-specific bugs were annoying (2) there's a token amount of physical aarch64 hardware now. Unfortunately, it doesn't seem to work. Again.
<lfam>It's still somewhat early days for Guile on aarch64
<nckx>(grunewald, kreuzberg, and overdrive1).
<nckx>(All idle.)
<j`ey>aarch64 is where my interests lie
<lfam>Isn't there some Guile bug that crashes the Cuirass workers on aarch64, causing these issues?
<jgart>nckx, I started yet another wiki here also which includes a wish list: I prefer it to the libreplanet one because the wiki is in markdown and under git. We also have the wishlist entries linked to our issue tracker:
<j`ey> doesnt load either
<lfam>I'm not sure what it's supposed to show
<nckx>But it's being used, unlike -130.
<nckx>I think there was one busted node, so that makes sense.
<lfam>I see
<j`ey>and the RAM size shows 0b
<nckx>It's also a PDP-11 if the uptime is to be believed (better not).
<nckx>So 0b, rounded down, would be about accurate.
<nckx>As pretty as those graphs are, they aren't high priority, but feel free to open a bug if it bugs you.
<lfam>Potential Guile bug breaking Cuirass on aarch64:
<lfam>And upstream report:
<rekado_>130 has problems
<mekeor[m]>jgart: ugh why would you start a new wiki without trying to convince the whole guix project before
<rekado_>same with 119
<rekado_>we had a Dell service technician in the data centre on Friday, and will have them again on Monday.
<rekado_>119 seems to be a broken CPU; 130 has some problem with the disk controller
<nckx>jgart: If you want to add it to the list on LibrePlanet, go ahead, 's only fair.
<lfam>It's easy for us to forget the scale of the build farm, rekado_. Thanks for your effort
<nckx>rekado_: Eek. Nice to hear it's under service contract, though. I realise I wasn't expecting that in retrospect.
<jgart>mekeor[m], It's not meant to replace or substitute for any other wiki. It's *yet another* wiki. It's convenient to use markdown and git for a wiki. See any other points above as to why. Feel free to start a wiki also if it's convenient for you or use the LibrePlanet one or the other one, and/or yet the other one, etc...
<mekeor[m]>jgart: imho, yet another wiki sucks, because it's cumbersome to have knowledge spread all over. also, i am not against using a markdown&git based wiki, if the guix devs (and maintainers) agree on it as official wiki
<nckx>But that's not realistically going to happen regardless.
<jgart>mekeor[m], which wiki are you currently using?
<mekeor[m]>nckx that's sad but ok
<mekeor[m]>jgart: none because the manual suffices for me
<jgart>We just sent a patch to contribute to the manual:
<jgart>I use the manual, videos, wikis, books, parens hypnosis etc... to learn guile/guix
<jgart>If the manual suffices for you that's awesome, but I'm a poor soul who needs all the above and then some
<tribals>Hi, folks!
<tribals>I'm trying to adapt to guix home, here is my "hello-world" environment:
<excalamus>hi, tribals
<tribals>Unfortunately, reconfigure of even this simple environment leads me to error
<tribals>guix home: error: setlocale: Invalid argument
<tribals>can't figure out what's wrong with that?
*podiki[m] notices the new fanciness on Matrix, catches up on that and YAWD
<podiki[m]>(yet another wiki debate)
<mekeor[m]>jgart: nice patch submission. texinfo really sucks. imho, i guess that's one of the disadvantages of being a GNU project: you need to stick to GNU solutions?
<tribals>Currently I'm using guix on foreign distro, and haven't installed any packages yet to my profile, so each invocation of guix command spits out hint about installing glibc-locales
<singpolyma>tribals: yeah, it's annoying but I've just learned to ignore it
<tribals>but what to do with `guix home`?
<podiki[m]>I haven't looked at texinfo source before, but presumably org-mode -> texinfo would work well
<nckx>podiki[m]: There really is no fanciness beyond ‘nckx logged into the thing a year too late and update the room picture & title’.
<mekeor[m]>podiki: new fanciness?
<mekeor[m]>ah got it now :)
<podiki[m]>mekeor: it has a nice logo image and title
<podiki[m]>I had finally set the guix logo for my collection of matrix rooms/chats the other day too
<nckx>Thanks to podiki[m] for reminding me how Matrix worked.
<podiki[m]>nckx: a little image and title goes a long way! so professional now :)
<civodul>tribals: those locale warnings, are these from Guix 1.3.0 or current master?
<civodul>and does following the hints help?
<mekeor[m]>is it just my personal limited impression, or do former guix maintainers now spend more time here in the irc channel?
<civodul>i think it's an impression :-)