IRC channel logs


back to list of logs

<rekado_>apteryx: i’ve wanted to have a -S for guix shell just as in guix pack
<lechner>unmatched-paren: is there another way to debug why the tests are not working for this module?
<lechner>unmatched-paren: for gocryptfs i decided to go just with 'go test', which seems to work as well. the error handling is not great though
<lechner>i meant i stayed with 'check
<rekado_>I’d be happy if someone could help me package binutils 2.11 or 2.14a.
<rekado_>I have built both but their “as” executables segfault immediately
<lechner>rekado_: which architecture are you on?
<lechner>Hi, I am nearly done packaging 'gocryptfs'. Is a separate file like this in gnu/packages acceptable?
<apteryx>rekado_: I'm trying!
<Zambyte>Hi, does anyone use pipewire for audio instead of pulseaudio on a Guix system? I have pipewire and wireplumber installed, but it seems like everything wants to use pulse instead, even going as far as depending on and launching pipewire
<jab>Zambyte: I think there are some people manually starting pipewire.
<jab>It is not the default yet.
<lechner>apteryx: which package definition for binutils are you using, please?
<Zambyte>jab: do you know of any example configurations? I have a home shepherd service for pipewire but I'm still having trouble
<jab>Zambyte: I do not know of any. But unmatched-paren probably knows how. He helped me set up seatd the other day.
<Zambyte>Alright :) I'm going to brb
<apteryx>lechner: I'm not sure the question was meant to me (w.r.t. binutils) ? :-)
<apteryx>rekado_: a proof of concept that special cases /usr/bin/env:
<apteryx>it works, so all the tooling is already there
<lechner>apteryx: okay, sorry. was just trying to help
<apteryx>lechner: eh, no need to be sorry, thanks for offering to help :-)
<sneek>Welcome back vagrantc :D
<vagrantc>sneek: nice to see you too
<xigua>are there any pros or cons of installing your window manager (and bar, compositor, etc.) in the user home config vs the system config?
<xigua>because currently I do put things related to X in my system config but I'd rather be able to update somethings sooner than I update things like the kernel
<jab>xigua: probably guix home is better...
<jab>but I currently do not use it.
<podiki[m]>I don't either
<podiki[m]>but my system config has basically no packages except for things like udev rules etc
<xigua>okay so I will put the rest in my home config, just making sure there weren't problems with that. thx! :)
<lechner>Wow, 'guix deploy' in action is the coolest thing I have seen in ten years. Well done!
<johnabs[m]>Hi all, I've got another question (I think it'll be easy this time). I installed Julia 1.6.7 from guix and tried to use the typical "] add <pkg-name>" and this fails with a very strange curl error. I understand I can use guix to manage my Julia packages, but I'm not interested in that for the moment, as I'm in a more research focused context. Any ideas on getting Pkg.add working again?
<johnabs[m]>Oh, the error I'm getting is this: curl_multi_socket_action: 8
<lilyp>xigua if you use gdm I think you need the wms in your system config to allow switching between them
<lilyp>if you don't need that, you can put them in your guix home, though
<lilyp>johnabs[m]: knowing modern "package management" I'm p sure that if you don't fail on the download you will fail when trying to write to the store
<johnabs[m]>lilyp: I don't think it should write to the store, I'm pretty sure it writes to ~/.julia, right?
<lilyp>idk what julia does
<johnabs[m]>Julia is actually pretty good when it comes to this stuff, I think
<johnabs[m]>At least it's not python lmao
<xigua>lilyp: I use sddm at the moment, and earlier this year I tested a different wm just by adding it to home and it showed up, but I'll find out and update here if it ends up being important
***TopExpert is now known as kingmaker
<Schmoho>Hey, I am experiencing an issue which fundamentally breaks guix as a secondary package manager for me - the isolation is broken and applications installed via my primary package manager link against a libpthread in the gnu store.
<Schmoho>I don't really know how this happened and what I can do about it. I'd be super glad if someone can help me with it
<Schmoho>This is the output from `LD_DEBUG=libs chromium`
<Schmoho>and this is my `env | grep -E '/gnu/store|guix'`:
<unmatched-paren>hello guix!
<abrenon>hey guix
<johnabs[m]>So I think I figured out my julia issue, but I think it's an issue with the package definition, which contains a patch to allow parallel builds
<johnabs[m]>Using guix install works on local .scm files, right?
<johnabs[m]>Or is there a way to tell guix to remove or ignore a specific patch?
<ulfvonbelow>fun guixgolfing trivia: what do you think the following evaluates to?
<ulfvonbelow>(let ((gexp (lambda (x) (+ x 1)))) #~3)
***Dynom_ is now known as Guest1343
<johnabs[m]>Holy crap, I think I did a thing?!
<johnabs[m]>We'll see if it works xD
<StefanCristian>two[m]: instruct me a bit on something. if I install guix package on a different distro, and just use guix system vm config.scm, it should install a chroot or a vm?
<johnabs[m]>From what I've read, a vm is apparently easier, but I am NOT an expert, so take that with a pound of salt
<lechner>StefanCristian: I think you do neither. My sense is that the Guix package manager transparently overlays Guix packages over whatever your operating system provides. Personally, I think it's a stop gap solution if you do not have admin rights, however, and switched to Guix System on all of my equipment
<StefanCristian>lechner: that's a bit bad, but understandable.
<StefanCristian>also what I presumed it would do as well
<linj>How to call a function in repl if its parameter is os?
<lechner>StefanCristian: i don't think it's bad at all. you can also do the VM thing if you want, but it gives you much less flexibility
<StefanCristian>lechner: it's bad for what I intend to do, and from my intentions one of them is not to dedicate a VM for it, but rather would be much easier to have the system in chroot and just contribute from there. usually any system that can run in a chroot is easily adapted to anything else
<lechner>StefanCristian: one of Guix main points is to untether users from your distro's package management. which os are you on?
<StefanCristian>lechner, doesn't really matter. all of the OSes points are to untether other people from their main OSes - and that's completely alright. but I generally prefer easily chrootable systems, instead of booting VMs
<lechner>StefanCristian: try to unthink
<StefanCristian>I think that back in the days it was easier, when we didn't have the possibility of starting VMs that easy.
<StefanCristian>We were just downloading a filesystem, mount whatever is necessary, and just chroot into it, and just jail applications
<lechner>StefanCristian: Guix may be far more powerful that you can imagine
<StefanCristian>I know it is, but it would be easier if I would just download a tar.xz. but not a biggie, though, most probably I'll end up unpacking the ISO and searching for a small filesystem to make it work
<StefanCristian>just additional effort
<lechner>at its core, Guix is a package manager
<StefanCristian>yeah, mostly all of them are
<StefanCristian>for example Gentoo has its filesystem as a archive
<StefanCristian>for installation, you just chroot into it, install kernel and bootloader, and you're done
<lechner>sounds more like an os to me
<StefanCristian>I don't install bootloader and kernel in a gentoo
<StefanCristian>I usually keep it as chroot
<StefanCristian>sometimes I need to compile-optimize some specific programs, and test them via systemd-nspawn or jail
<StefanCristian>with currently working kernel
<StefanCristian>if I would do that as VM, it would take more effort, since apps don't start the same kernel as my host machine
<StefanCristian>or same libs
<StefanCristian>as chroot, I can share any kind of libs from main host to the filesystem in situation, such as guix or gentoo if it's the case
<StefanCristian>makes tests much, much easier
<lechner>StefanCristian: in Guix, chroots are not needed. the isolation happens via absolute path names (and environmental variables). it is the most ingenious system i know
<lechner>there are no relative paths in Guix
<StefanCristian>that's a different subject
<lechner>StefanCristian: that's what i have been trying to tell you
<nckhexen>Good morning, Guix.
<rekado_>StefanCristian: you can run Guix System in a container.
<nckhexen>StefanCristian: There are some extremely bare-bones chrooting instructions here: <> but lechner is right, some of your expectiations like ‘sharing libs’ are just not going to happen and could indicate a fundamental misunderstanding. This is not Gentoo.
<rekado_>StefanCristian: see here:
<nckhexen>Don't all distributions install into a ‘chroot’ by this definition of ‘chroot’ (directory)? Anyway, that's all ‘guix system init FILE /DIRECTORY’ does. That /DIRECTORY is usually a mounted target block device doesn't really matter. It doesn't have to be.
<pkill9>Schmoho: my immediate guess is maybe you installed development tools with guix that set an environment variable that adds guix's libraries as a target to compile against
<nckhexen>sneek: later tell ulfvonbelow: Without chea^Wchecking… I'm going to go with 4, and nice try, trickster. ☺
<sneek>Will do.
<nckhexen>Schmoho: Also, this question might get more answers on the help-guix at mailing list.
<cbaines>is there a way to just offload i586-gnu stuff to a childhurd?
<cbaines>I'm not very familiar with offloading, and I'm wondering if I won't be able to build x86 stuff once I configure it
<nckhexen>cbaines: Offloading will only trigger for architectures in the build-machine's systems list.
<nckhexen>(Barring bugs, but that doesn't sound like your primary concern.)
<cbaines>so, if I just have a list of machines only containing the childhurd, it should be fine?
<nckhexen>More that if you have (systems (list "i565…)) but yet.
<Schmoho>okay thanks I'll try my luck there and check if there is some development tooling issue going on
*nckhexen quietly corrects i565 to i586, not yet willing to share today's i965 VA-API trauma with the world.
***wielaard is now known as mjw
<pkill9>protip: don't burn yourself out from coding by spaghetifying yourself into oblivion
***Dynom_ is now known as Guest1371
<apteryx>cbaines: there is, I was doing that for a while
<apteryx>the 'build-machine' record has (systems (list "i586-gnu"))
<apteryx>and the host serving the child-hurd VM has this config:
<apteryx>not sure if it works anymore, I haven't used it in a while; typically the wireguard link goes down because of my dynamic IP
<cbaines>Ok, I might try this at some point this week
<cbaines> now has connected childhurds, but coreutils and grep fail to build, so not much has been built
<cbaines>having a childhurd to offload to might be helpful in trying to work on this
<pkill9>stock gnome is pretty nice
<lechner>cbaines: thanks for the golang gitignore update!
<lechner>nckhexen: what happened with the intel video driver?
<cbaines>lechner, I'm not sure what that is?
<andi-[m]>Do I have to add some specific package to my system configuration / some service in order for hardware accelerated video playback to work with a AMD card that is otherwise fully supported by mesa?
<nckhexen>andi-[m]: What does ‘fully supported’ mean?
<andi-[m]>Meaning I usually don't need any 3rd party software pieces.
<nckhexen>So no firmware?
<andi-[m]>I knew you were going into that direction.
<nckhexen>It is an obvious question.
<nckhexen>lechner: Couldn't get it to work on my mother's machine, and now she will withold pie from me, probably.
<andi-[m]>It is one that I particular have no interest in discussing. This is a mesa feature that should be accessible via vdpau which is something that guix is using.
<nckhexen>OK. We won't discuss it then.
<lechner>nckhexen: yeah, WhyPad is best for moms
<lechner>cbaines: just this
<lechner>nckhexen: the proprietary tablet solution
<cbaines>ah, cool :) I forgot about the package name
<lechner>cbaines: while i have your attention, also thanks for all those quality substitutes!
<nckhexen>lechner: I knew you'd disappoint me one day.
<cbaines>lechner, you're welcome, it's not all my doing, but it is something I've been working on
<cbaines>(and something that I'm regarding as pretty much solved now)
<lechner>cbaines: i'd like to offer a mirror stateside one day
<lechner>nckhexen: my dad provides it
<abrenon>how do inclusion path with java ? I spawned a shell with jdk and some library (java-commons-io) but jshell doesn't seem to find it
<abrenon>isn't it like with python, haskell and all the rest ?
<drakonis> neat, this.
<apteryx>rekado_: instead of symlinks in containers, it seems we can achieve the same with bind mounts; would that be good enough? it's simpler to implement
<apteryx>(since bind mounts are already used for --expose or --share mappings)
<lechner>Hi, for 'guix deploy' I use Guile 'load' to tie the operating-system (the /etc/config.scm from the stand-alone system) into the machine.scm used by 'deploy'. On the target system's console, I see "WARNING: Use of 'load' in declarative module. Add #:declarative #f to your define-module invocation." There is no such invocation anywhere. What should I do, please?
<gnucode>afternoon guix!
<gnucode>btw, I feel like just by joining this chat room, the average person increases their IQ by 50 points.
<tricon>howdy, gnucode.
<kaelyn>rekado_: Not sure if you saw it, but I replaced (which apparently auto-closed from inactivity) with which updates vulkan on core-updates to sdk
<kaelyn>(there is also which bumps mesa on core-updates to 22.2.1 and fixes its vulkan layer manifests)
<lechner>kaelyn: it may have been closed intentionally when a separate branch was created
***dongcarl is now known as Guest1624
***dongcarl8 is now known as dongcarl
***sjs is now known as Guest4901
***jpoiret2 is now known as jpoiret
<unmatched-paren>noooo, come back sneek! D:
***jfb4_ is now known as jfb4
<unmatched-paren>sneek: botsnack?
<unmatched-paren>nope :(
<abrenon>: )
<nckhexen>RIP to all who lost their lives in the excess flood.
***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*
***litharge sets mode: -o litharge
<nckhexen>Hm. That actually fixed it. I wonder if #guix (or #guix + #guile) has become too big for sneek.
***ChanServ sets mode: +o litharge
***litharge sets mode: -bo *!* litharge
<nckhexen>sneek: botsnack
***justache is now known as justHaunted
<lechner>sneek: botsnack
<abrenon>yay, sneek is back !
<gnucode>tricon: howdy to you too!
<lechner>tricon: hi!
***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*
***litharge sets mode: -bo *!* litharge
<linj>Could anyone point me to the manual of this `let*` syntax in this code:
<nckhexen>(guile)Local Bindings
<apteryx>(srfi srfi-71)
<apteryx>it's confusing in that it shadows regular let*
<nckhexen>Oh, my bad.
<apteryx>but otherwise it's a more ergonomic way to use multiple return values
<apteryx>info '(guile) SRFI-71'
<linj>thanks, quite confusing for a newbee
<nckhexen>Haha yes newbie.
<nckhexen>(That was me mocking myself, not you, to be clear.)
<apteryx>looking at the (guix scripts environment) option parser, I'm puzzled as to why it's OK to tack new 'file-system-mapping keys without concatenation
<apteryx>since multiple --expose are supported, it seems you'd end up with an options alist that has multiple 'file-system-mapping keys
<apteryx>best way to know... pk
<apteryx>ah, it does add multiple entries with the same key, but that's then treated via pick-all: (mappings (pick-all opts 'file-system-mapping))
<apteryx>which docstring is: "Return a list of values in ALIST associated with KEY."
<linj>Can I apply this procedure in the repl? It needs `os` as its argument.
<nckhexen>linj: The answer is ‘yes’, but you clearly mean something more?
<linj>yeah, I want to know how
<nckhexen>But how what?
<nckhexen>Is (load "/etc/guix/system.scm") a relevant answer?
<nckhexen>You can apply any procedure in the REPL, so…
<nckhexen>Or maybe the answer you mean is (@@ (gnu system) operating-system-bootloader-crypto-devices). I can't tell.
<lechner>Hi, why does using git send-email make it easier to review patches than when the output of format-patch was attached to the filing via MIME, please?
<lechner>one per message, that is
<unmatched-paren>lechner: at least in the email client I use (aerc), i can hit "rq" and get the patch as a quote in a new message i can annotate
<unmatched-paren>it's very difficult to do something similar with an attachment
<lechner>unmatched-paren: i was just thinking of you!
<unmatched-paren>there's probably a similar situation with other mail clients...
<lechner>unmatched-paren: is there an order to the packages in g/p/golang.scm?
<unmatched-paren>lechner: try to add packages there near other similar packages
<unmatched-paren>but there's no alphabetical order
<unmatched-paren>unlike in crates-io.scm
<linj>nckhexen: (load ...) works for me, thansk. BTW, what does @@ mean?
<unmatched-paren>linj: @@ is a "force retrieve from module" operator
<nckhexen>It extracts unexported symbols from modules, and I didn't check whether the procedure you want is exported because here.
<unmatched-paren>(@ (foo bar baz) quux) gets the *public* variable quux from (foo bar baz)
<unmatched-paren>(@@ (foo bar baz) quux) gets it regardless of whether it's public or not
<nckhexen>It kept scrolling to wrong places.
<lechner>unmatched-paren: also, why should nine, mostly tiny prequisites be submitted as separate patches? many of them "belong together" and would not apply independently anyway
<nckhexen>Why wouldn't they apply independently?
<nckhexen>If they are interdependent, and there's no way to break the cycle, multiple packages in one patch are acceptable.
***mark_ is now known as mjw
<lechner>nckhexen: they would not apply independently because being next to each other in the same file, subsequent patches would depend on the context from a prior patch
<unmatched-paren>they can depend on the context from prior patches
<nckhexen>lechner: But that's the case for most patches.
<unmatched-paren>but they must still be separate
<nckhexen>And fine.
<lechner>nckhexen unmatched-paren: is that so something can be reverted?
<lechner>this is for btw
<nckhexen>I'd say it's more to keep things brainable for humans, for the same reason well-written procedures are short and simple. Like Unix, a patch should do one thing. For that reason it does help one keep track of things in complex rebases, yes.
<nckhexen>(But unlike Unix, patches should do that one thing well!)
<unmatched-paren>how can i open doc/ in Emacs info-mode?
<nckhexen>unmatched-paren: C-u C-h i
<unmatched-paren>hmm, that doesn't seem to have worked
<unmatched-paren>it just opens Top normally
<vagrantc>poor sneek
<linj>How do I override the `operating-system-bootloader-crypto-devices` procedure defined in (gnu system)? I tried to override it in my config.scm, but that didn't work.
<unmatched-paren>wdym "override"?
<linj>change its definition
<unmatched-paren>why? :)
<linj>currently, my setup is not supported: /boot on luks1, / on luks2
<unmatched-paren>i don't think luks2 is supported at all yet
<unmatched-paren>and overriding one procedure is unlikely to make it work
<linj>yeah, I find several open issues about luks2
<linj>I guess I need to use a forked guix channel to override it
<unmatched-paren>it'll probably require more than overriding a procedure, though...
<unmatched-paren>otherwise it would have been done already.
<linj>a few places need to be changed
<linj>e.g. copying kernel and initrd to /boot from store
***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*
***litharge sets mode: -o litharge
<lechner>Hi, I would like to cc the Go team on a patch series. Does the team have any members?
<nckhexen>unmatched-paren: I cannot reproduce that. It goes straight to ‘GNU Guix’.
<unmatched-paren>nckhexen: Ah, it's probably because evil-mode overrides (or more specifically provides a disabled-by-default option to override) C-u.
<nckhexen>And it's the git version, not the one I get with ‘info\nguix’.
<unmatched-paren>(in Vi, C-u is "go up half a screen".)
<tricon>Convincing your work place to invest in more Guix servers: Feels good.
<tricon>Yah. Should be able to kill off two more Win servers in favor of Guix. #freedom
<nckhexen>Oh, wow, even better.
<nckhexen>o7 for your service.
<tricon>Much love to the whole team and community.
<tricon>I got to crack the joke, "Yeah, MS officially recommends all future Win servers be headless... after 40 years."
<tricon>So: May as well be Guix headless.
<nckhexen>I don't really get the joke, but that probably makes me lucky.
<lechner>Windoze always seemed headless to me, anyways (for another joke)
<johnabs[m]>Ok, so I tried packaging julia myself, but the build failed for some reason. Now I've downloaded the binary to try to run it, but I get an error "file not found" from bash, even though I'm in the appropriate directory that would normally work with a shell script. Any reason this would be happening? According to ldd, all the deps are present.
<lechner>Hi, how may I install git:send-email when using only variables and not specifications in my home config, please?
<unmatched-paren>lechner: (list git "send-email")
<morganw>"Yeah, MS officially recommends all future Win servers be headless... after 40 years." ... It is the default on the installer, but it doesn't mean software actually works with it. Even some of the built-in server roles don't work with it.
<nckhexen>I have now inferred that Windows servers aren't headless. I don't know what to do with that information. It sure explains… things.
<unmatched-paren>"not headless" here means "it comes with a GUI"...?
<morganw>It has a minimal GUI, so technically I wouldn't say it was headless. Presumably more things will break when there is actually no display.
<lechner>unmatched-paren: thanks!
<vagrantc>builder for `/gnu/store/r3y5jir2dv5inrfkqhjgzkvdh7lmqh5m-guix-package-cache.drv' failed to produce output path `/gnu/store/p8926hbpnrrdb9d3awzrnp75i4x9y7v1-guix-package-cache'
<vagrantc>it's back.
<vagrantc>that's what i get for not investigating further before
<vagrantc>seems unrelated to the commit i'm pulling.
<vagrantc>guess it's time to file an inscrutible bug report
<vagrantc>plenty of disk space, plenty of inodes ...
<lechner>vagrantc: on which file system?
<nckhexen>Is this the old dir_index story again?
<nckhexen>vagrantc: In which case, tune2fs -O ^dir_index .
<vagrantc>worth trying ...
<lechner>vagrantc: i find the 'open' limits low and use (pam-limits-service (list (pam-limits-entry "*" 'both 'nofile 100000)))
<vagrantc>at the moment, i'm trying ... sudo guix gc --verify=repair,contents
<nckhexen>vagrantc: ‘plenty of disk space, plenty of inodes’ implies you suspect ENOSPC, but is that actually the error?
<vagrantc>nckhexen: i'm grasping at straws
<nckhexen>It's only worth trying that option if you do.
<apteryx>rekado_: technically this should work for 'guix shell --symlinks', but it silently fails my 'guix shell --symlink=bin/bash=/bin/bash -C bash coreutils' test (/bin/bash doesn't exist)
<nckhexen>vagrantc: Then that is too unlikely IMO.
*vagrantc digs up a failed build log for fun
<tricon>morganw: that's actually a good point.
<nckhexen>vagrantc: I would not file a new bug report:
*vagrantc looks at the bug
<nckhexen>I think you have more info than the reporter of that bug ever did.
<nckhexen>vagrantc: I don't have that variable either.
<vagrantc>at least two photons, one for each eye
<nckhexen>It must be ancient.
*vagrantc downloads the bug history and gets to work
<nckhexen>When did we remove python2 stuff?
<nckhexen>And why is your Guix so elderly?
<nckhexen>I mean, the one you're trying to build.
<lechner>i don't see python2-pygtk either
<nckhexen>Anything python2 will be long gone.
<nckhexen>Maybe some weird channel has it, but that too is grasping at straws ☺
<nckhexen><seems unrelated to the commit i'm pulling> is what makes that part weird.
<nckhexen>Get out your snacks.
***ChanServ sets mode: +o litharge
***litharge sets mode: -bo *!* litharge
<vivien>sneek, botsnack
<nckhexen>(For those wondering what these bans are about: sneek floods out when connecting to all channels at once, so banning her even for a few seconds here avoids those limits hitting all at once.)
<vagrantc>nckhexen: well, what's aboslutely confusing is my guix is from earlier this month, and pulling to somewhat recenter commits ...
<vagrantc>guix-daemon is definitely old, though
<nckhexen>If the daemon is injecting an old python2 package into the cake mix that is anything but reassuring, but odds are vanishingly small.
<vagrantc>nckhexen: by unrelated, it means i tried building every commit between the one that last suceeded and current guix master at some point
<nckhexen>vagrantc: No clue where that package might be coming from? Forgotten configuration?
<vagrantc>it's just a plain ol guix pull
<vagrantc>worked around it by downgrading, but then it reappeared
<vagrantc>e.g. building with an older guix pull instance
<vagrantc>sent slightly more (confusing) details now to the bug report you mentioned
<nckhexen>Well, that was before you shared your paste with the python2-pygtk culprit.
<nckhexen>But thanks!
<nckhexen>In hindsight, a new bug report would have been fine, but that's on me. I thought you had no further error messages.
<unmatched-paren>what's this error (when building guix-package-cache) about?: (values (non-self-quoting 2052 "#<unspecified>")
<unmatched-paren>that's all i get...
<nckhexen>Uh, that's another blast from the past.
<nckhexen>What is going on.
*nckhexen pulls.
<vagrantc>ci seems to build it just fine
<unmatched-paren>i'm using two other channels, guixrus and (that other one), which is probably related...
<nckhexen>python2-pygtk implies they are not the same ‘it’.
<nckhexen>That string simply does not, and should not, appear in current Guix code.
<nckhexen>unmatched-paren: It doesn't forgive the useless error message, but it does sound likely.
<unmatched-paren>nckhexen: i've just pushed a bunch of commits to guixrus to try to fix it after the removal of those 100-and-something leaf rust libraries
<unmatched-paren>so it might be something to do with those
<unmatched-paren>though i don't know what it could possibly be
<nckhexen>Oh, OK, yeah, that is likely just from those numbers alone. Thanks for the reassurance (and I didn't know you committed to guixrus—nice!)
<rekado_>unmatched-paren: this (values (…)) stuff is just “guix repl” talking. Here it says that it has received a value that it can’t serialize.
<nckhexen>I can't reproduce any ‘guix pull’ failures.
<unmatched-paren>nckhexen: why from "just those numbers alone"?
<unmatched-paren>what's special about the number?
*rekado_ built GHC 4.08.2 with the 3.8MB blob of generated C “source” files. And it doesn’t segfault.
<unmatched-paren>rekado_: \o/
<vivien>Hello, I’m writing a guile program and I’d like to run tests for the log module. The log module uses date->string at some point, so I make sure to set LC_ALL so that the date locale format is consistent with my expectations, but guile does not get the timezone right. Prior to my tests, I have: (setenv "TZ" "CET") (tzset) but I still get the dates with no timezones (Tue Oct 25 19:19:07Z 2022 [not the current date]). I specul
<vivien>ate that no timezone is available in the build environment of my package, so guile can’t do anything. Am I correct? Or is there something more to do with guile?
<unmatched-paren>vivien: maybe #guile would be a better place for this question?
<vagrantc>nckhexen: yeah, uh, well, sure. no idea where python2-pygtk is coming from.
<vivien>I think not
<unmatched-paren>ah, right, i didn't notice "in the build environment"
<unmatched-paren>sorry! :)
<vivien>No problem :)
<nckhexen>vivien: Is the TZ data (tzdata-for-tests) available?
<nckhexen>Your package is certainly not odd or unique for that, so if the data is available, it should just work.
<vivien>Should I add tzdata-for-tests as a native input?
<apteryx>ah, did I just get the --symlink spec reversed again, eh.
<nckhexen>unmatched-paren: Nothing special, just big, and likely to hide something like ‘oops we evaluate garbage now’, which otherwise is (one hopes) easy to spot.
<vagrantc>ok .... found a reference to wicd (and presumably python2-pygtk) in a stale ~/.cache/guix/checkouts/ ...
<vagrantc>a cleverer me would have backed up those up and put them somewhere else
<vagrantc>but this universe has the me who just purged them.
<nckhexen>It will hamper debugging somewhat 😛
<vagrantc>it does not appear to be the checkout it was actually using though
<unmatched-paren>looking at the five commits i just pushed, i don't see anything *obviously* wrong...
<vagrantc>and ... guix pull is ... pulling the same commit ... and spending some cycles to figure that out
<two[m]>in trivial-build-system what is the source path?
*vagrantc waits for another commit to test
<vagrantc>though, i suspect if it was in fact the stale ~/.cache/guix/checkouts ... there may be a real bug there somehow
<vivien>nckhexen, guix build now says: environment variable `XDG_DATA_DIRS' set to … :/gnu/store/xxx-tzdata-2022a/share:… but still not the expected timezone. I have created a custom phase that setenvs "TZ" to "CET" but still nothing.
<apteryx>rekado_: it works! I had simply reversed the spec
<apteryx>ah, and needed to provide "." as the target of evaluate-populate-directive, rather than profile
<vivien>Mmh the r package has setenv TZ but also setenv TZDIR
<vivien>And #:disallowed-references (list tzdata-for-tests)
<vivien>as an argument
<vivien>What does #:disallowed-references mean?
<vivien>Oh nevermind I don’t need it, I only needed the tzdir
<rekado_>vivien: disallowed-references is a sanity check; when the resulting output has a reference to any of the listed packages the build fails.
<vivien>So maybe I need it after all
<rekado_>you can do without it
<rekado_>it’s just ugly to embed a reference that only takes up space
<vivien>Oh I have to do that
<rekado_>apteryx: good progress!
<vivien>A self-contained pack of my guile + gtk application is 2 Gb
<two[m]><two[m]> "in trivial-build-system what..." <- when i want to refer to it in the builder expression is it current?
<vivien>Granted it’s maybe not tzdata
<rekado_>it would be nice if we had a way to run arbitrary filters on pack
<rekado_>“guix pack” copies stuff from the store to an archive. If we could add a custom predicate procedure we could perhaps avoid adding stuff that is known to be useless
<vivien>I think it would be better to run the filter before building the package, so we would get a chance to cross-compile more things
<vivien>For instance, if I have libfoo as an input, but libfoo also install bar, a perl script, then cross-compiling my package requires a cross-built perl, but I don’t need it
<vivien>Well that’s not smart in fact
<vivien>Or is it
<nckhexen>It is a check, not a filter. It doesn't remove anything for you.
<nckhexen>s/check/assertion/ if that's more clear.
<vivien>I get that, but rekado_ was dreaming about a filter
<rekado_>vivien: before *building* a package? That would be a new build. You could probably abuse grafts for this.
<vivien>Another item to put on the list of things to learn about guix
<vivien>But I have heard about it quite a few times, so it gets higher and higher
<two[m]>are there examples for usage of trivial-build-system?
<vivien>There’s markdown
<tricon>two[m]: i always grep the Guix source for such.
<unmatched-paren>you almost certainly don't want to use trivial-build-system
<rekado_>vivien: grafts involve an original package “oh-no”, a slightly modified variant of that package (“oh-yeah”), and packages that have “oh-no” somewhere in the inputs (recursively).
<unmatched-paren>use gnu-build-system or copy-build-system with phase replacements instead
<rekado_>“oh-no” is bad, and we don’t want to use it. So we build “oh-yeah” and say that it replaces “oh-no”.
<rekado_>now we just need to make all those packages that currently use “oh-no” use “oh-yeah” instead.
<vivien>Ah yes that’s the tricky part
<vivien>Can I do that in a channel to replace official packages?
<two[m]>it's (assco-cref %build-inputs "source")
<rekado_>so we create new variants of all those packages — but instead of building them from source we just *copy* all files and replace any textual reference to “/gnu/store/…oh-no” with “/gnu/store/…oh-yeah”.
<rekado_>we do this for all packages using “oh-no” and all packages using those packages, recursively
<unmatched-paren>(assoc-ref %build-inputs "source") can be replaced with #$(package-source this-package), i think
<rekado_>that’s what a graft derivation is: it just copies a directory /gnu/store/1234foo and produces a new directory /gnu/store/2345foo where all references to “oh-no” have been replaced with “oh-yeah”.
<vivien>rekado_, by textual reference, you mean in text files, or also in binaries (executables and libraries), or in any file?
<rekado_>vivien: no, you need to change the package definition of “oh-no” to add a “replacement” field that points to the new package.
<rekado_>vivien: in any file; we replace just the string “/gnu/store/…”
<vivien>So if the strings are not of the same size it could mess up binary file formats where the input is a string length followed by string bytes, right?
<rekado_>this is why we do take care of string length
<vivien>I’ll wear a costume of that for halloween
<vivien>Oh ok
<rekado_>you can’t actually replace “oh-no” with “oh-yeah” – but you can replace “oh-no-1.12” with “oh-no-1.13”
<vivien>So the string lengths are checked and the graft fails if they don’t match?
<vivien>What if there’s simple unicode in the file names and guile checks the number of code points but the file format expects the same number of UTF-8 bytes?
<vivien>Oh maybe it’s just the package version that is expected to differ
<vivien>Not the individual files
<vivien>And I guess it is OK for guix to require version numbers to be ASCII
<lechner>vivien: Hi, I use this for timestamps like "Tue 25 Oct 2022 01:54:19 PM PDT" (strftime "%c" (localtime (current-time)))
<rekado_>vivien: the version number may stay the same. The hash changes anyway.
<rekado_>vivien: now you see (one of the reasons) why we can’t install compressed files to the store; because we wouldn’t be able to see references to /gnu/store/….
*rekado_ moves on to building ghc 6.0
<vivien>evince does not let me zoom enough to read package names in the guix graph output >:( I’ll try another format
<silasfox>Hey guix!
<vivien>(oh theres -M)
<silasfox>I'm trying to get my printer working with GuixSD and I need gutenprint drivers for that. I found this patch (, but I don't know how to apply that. Can anybody help me with that?
<jonsger>silasfox: inside a git checkout of guix repo something like "curl | git am"
<jonsger>and then follow the steps of how to build Guix from a git checkout, somewhere in the manual :)
<silasfox>jonsger: Thank you, I'll try that.
<apteryx>is there a test for container support when running sh tests?
<apteryx>I see a 'skip-if-unsupported' in tests/containers.scm, but there doesn't seem to be a way to use that in .sh yet
<apteryx>also, it'd be nice that 'guix repl' accepts a script from stdin
<vivien>I have qtbase as a reference in my package, can guix tell me which dependency has it as a dependency?
<antipode>guix graph --type=references + feed it to 'dot'
<vivien>The output is too huge, I can’t read it all
<two[m]>does trivial build even support gexps?
<nckhexen>vivien: --type=path?
<nckhexen>--path, even.
<nckhexen>I guess it's not even worthy of the name.
<antipode>vivien: Also, --max-depth
<nckhexen>two[m]: All build systems do.
<vivien>The problem with --max-depth is qt is too deep
<two[m]>nckhexen: how do you use it?
<nckhexen>That is two[m] vague a question.
<two[m]>i get "unbound variable: gexp"
<antipode>Then import it, (use-modules (guix gexp)), and double-check your quoting.
<two[m]>antipode: i did import that
<antipode>I recommend against nesting it in another level of 'quote' (i.e., (arguments '(#:foo ... #:bar)) quoting, likewise for quasiquote.
<two[m]>oh i had to put a command before #~
<two[m]>thank you
<two[m]>`,#~` now
<vivien>The --path worked!
<vivien>Now gtk depends on qt
<antipode>two[m]: I recommend doing (arguments (list #:foo #~... #:bar ...)) instead, for more straightforward quoting.
<vivien>That’s something I didn’t expect
<two[m]>thank you
<two[m]>vivien: gstreamer?
<vivien>gst-plugins-bad more precisely
<vivien>But maybe others