<rekado_>apteryx: i’ve wanted to have a -S for guix shell just as in guix pack <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 <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? <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. <apteryx>lechner: I'm not sure the question was meant to me (w.r.t. binutils) ? :-) <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 :-) <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]>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? <johnabs[m]>Julia is actually pretty good when it comes to this stuff, I think <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'`: <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? ***Dynom_ is now known as Guest1343
<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 <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 <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 <lechner>at its core, Guix is a package manager <StefanCristian>for installation, you just chroot into it, install kernel and bootloader, and you're done <StefanCristian>sometimes I need to compile-optimize some specific programs, and test them via systemd-nspawn or jail <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>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 <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>StefanCristian: that's what i have been trying to tell you <rekado_>StefanCristian: you can run Guix System in a container. <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. ☺ <nckhexen>Schmoho: Also, this question might get more answers on the help-guix at gnu.org 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>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>bordeaux.guix.gnu.org 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 <lechner>cbaines: thanks for the golang gitignore update! <lechner>nckhexen: what happened with the intel video driver? <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. <andi-[m]>I knew you were going into that direction. <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. <lechner>nckhexen: yeah, WhyPad is best for moms <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 <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 ? <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>btw, I feel like just by joining this chat room, the average person increases their IQ by 50 points. ***dongcarl is now known as Guest1624
***dongcarl8 is now known as dongcarl
***sjs is now known as Guest4901
***jpoiret2 is now known as jpoiret
***jfb4_ is now known as jfb4
<nckhexen>RIP to all who lost their lives in the excess flood. ***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*@cpe-24-29-202-168.neo.res.rr.com
***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 *!*@cpe-24-29-202-168.neo.res.rr.com litharge
***justache is now known as justHaunted
***ChanServ sets mode: +o litharge
***litharge sets mode: +b *!*@cpe-24-29-202-168.neo.res.rr.com
***litharge sets mode: -bo *!*@cpe-24-29-202-168.neo.res.rr.com litharge
<apteryx>it's confusing in that it shadows regular let* <apteryx>but otherwise it's a more ergonomic way to use multiple return values <linj>thanks, quite confusing for a newbee <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>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." <nckhexen>linj: The answer is ‘yes’, but you clearly mean something more? <linj>yeah, I want to know how <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? <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 <lechner>unmatched-paren: i was just thinking of you! <lechner>unmatched-paren: is there an order to the packages in g/p/golang.scm? <linj>nckhexen: (load ...) works for me, thansk. BTW, what does @@ mean? <nckhexen>It extracts unexported symbols from modules, and I didn't check whether the procedure you want is exported because tinyscreen.fail 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 <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>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 <nckhexen>lechner: But that's the case for most patches. <lechner>nckhexen unmatched-paren: is that so something can be reverted? <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!) <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. <linj>currently, my setup is not supported: /boot on luks1, / on luks2 <linj>yeah, I find several open issues about luks2 <linj>I guess I need to use a forked guix channel to override it <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 *!*@cpe-24-29-202-168.neo.res.rr.com
***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’. <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 <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. <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. <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. <vagrantc>builder for `/gnu/store/r3y5jir2dv5inrfkqhjgzkvdh7lmqh5m-guix-package-cache.drv' failed to produce output path `/gnu/store/p8926hbpnrrdb9d3awzrnp75i4x9y7v1-guix-package-cache' <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 ... <nckhexen>vagrantc: In which case, tune2fs -O ^dir_index . <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? <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. *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 downloads the bug history and gets to work <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. ***ChanServ sets mode: +o litharge
***litharge sets mode: -bo *!*@cpe-24-29-202-168.neo.res.rr.com litharge
<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 ... <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>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>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>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 <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. *rekado_ built GHC 4.08.2 with the 3.8MB blob of generated C “source” files. And it doesn’t segfault. <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? <vagrantc>nckhexen: yeah, uh, well, sure. no idea where python2-pygtk is coming from. <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. <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>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. <rekado_>it’s just ugly to embed a reference that only takes up space <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? <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 <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? <tricon>two[m]: i always grep the Guix source for such. <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>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 <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>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 <jonsger>and then follow the steps of how to build Guix from a git checkout, somewhere in the manual :) <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>I guess it's not even worthy of the name. <vivien>The problem with --max-depth is qt is too deep <antipode>Then import it, (use-modules (guix gexp)), and double-check your quoting. <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 #~ <antipode>two[m]: I recommend doing (arguments (list #:foo #~... #:bar ...)) instead, for more straightforward quoting. <vivien>That’s something I didn’t expect