IRC channel logs
2023-05-01.log
back to list of logs
<Michal_Atlas[m]>My very hacky solution for just testing packages and stuff is that it's sufficient to use guix -L . and a lot of guix's modules get successfully picked up even without pre-inst-env <Michal_Atlas[m]>And since the rest is taken from your environment then you can use time-machine or channels or anything <mirai>civodul: I'm looking at define-compile-time-procedure and regarding the comment in #62490, it doesn't look to me that it wouldn't work with symbols? <mirai>L133: (and (pred (syntax->datum #'arg)) ...) <Michal_Atlas[m]><TristanCottam[m]> "Michal_Atlas: Are there any..." <- Unsure, most probably doesn't work for more internal things, like editing anything about the daemon itself, for other things it was sufficient to me. <TristanCottam[m]>I got an error about a missing architecture, so I'm going the local channel route <bjc>well well well. look who's back for more <sughosha>Hi, I am trying to build zrythm, the same version that is still available in Guix (without pre-inst-env). It was getting built until I upgraded my recently. Here is the build log https://paste.debian.net/1279015/. <sughosha>zrythm is not the only one with this problem, many others like eog-plugins, geary etc. fails to build. <rekado>sughosha: what do the tests in btest_lto do? <rekado>sughosha: that’s from your paste <sughosha>Yes, I know. But I don't know why it is failing there. <rekado>have you built it with -K to look at the test logs? <sughosha>I can also share logs of some other packages which fail to build. <rekado>this is not zrythm failing; it’s libbacktrace <sughosha>rekado: Oh ok. I haven't tried building with -K option. Let me check now. <nckx>ACTION away, but, like, a normal period. <bjc>that's what you said last time! <gnucode>is there a way to tell guix to try to install a package, even though "make check" fails? <gnucode>qtbase@5.15.8 seems to not be installable on power9...because inkscape fails to build...that's odd. I guess I will try a guix pull. <ben-7549>Hi everyone. I am a new user of guix, and I quite like it. I’d like to participate and was wondering how to do. I saw that neovim is not at the latest version and I think it would be an easy first contribution. To do so, I should simply send a patch containing the version bump to guix-patches@gnu.org directly ? <gnucode>use git send-email for this task. The contributing section in the manual gives really good advice for how to do that. <Michal_Atlas[m]>Yep, also read through the whole section, it describes what label and description the commit should have and everything else you might want to know. <ben-7549>Ah right ! I didnot see that part in the manual so far. Thanks will check that first <kaelyn> hardware decoding fails with the console message "[ffmpeg/video] h264: No support for codec h264 profile 100." and I've seen the error with h265 files as well (the regression would mean my media mini-pc will no longer be able to play 4K videos after upgrading). <futurile>does anyone know how to run alacritty in a guix shell? I saw someone ask about it the other day so wondering if anyone has any success ... <RavenJoad>futurile: "guix shell alacritty -- alacritty" does not work? <old>I have a package that relies on Python. But the aclocal.m4 of the distributed tar.gz only define up to 3.9 in AM_PATH_PYTHON <old>the package was building fine prior to 3.10 <futurile>RavenJoad: ah should have been more specific, I'm trying to run it in a container - so trying to figure out what I need to share to get it to work <futurile>RavenJoad: so `guix shell --network --container --expose=/dev/dri --alacritty -- alacritty` sort of thing <rekado>old: you’d have to add a build phase or snippet to patch the check <RavenJoad>futurile: Ahh... That is more complicated. You are going to have to share a lot of things, because alacritty will need access to a lot of things. <civodul>mirai: at macro-expansion time, what the macro sees is not a symbol but a syntax object, like #'(quote x) aka. #''x <podiki[m]>kaelyn: there was a report the other day of a driver missing from mesa as well, so we should get both of those for the mesa branch; I will build a branch locally to see if it works and then see about how to do that with savannah/cuirass <podiki[m]>kaelyn: can reproduce the error but haven't tried with older mesa <mirai>is it possible to iterate over a record? <kaelyn>podiki[m]: sounds good, I'll see if I can find that report. I'm currently working on several patches for a mesa branch, including my existing patch for fixing the vulkan layer manifests, adding `VDPAU_DRIVER_PATH` as a native-search-path, updating to 23.0.3, and using gexps instead of quasiquote for the arguments. <podiki[m]>maybe we should compare (I did once long ago) our mesa build options to some other places to see if we've missed something or something changed in recent versions <kaelyn>For the hw decode issue I saw, it looks like mesa added a new video-codecs meson option with the default being an empty list. I checked the Arch and Debian package definitions, and both add "-Dvideo-codecs=vc1dec,h264dec,h264enc,h265dec,h265enc" <kaelyn>(added in one of the 22.x releases, as the commit for the new option was from 2022) <podiki[m]>very good, great; so we can do that on the mesa branch along with the driver that was missing (I think it was "crocus" if i recall) <old>rekado: I did that by adding a phase before configure to call autoreconf <kaelyn>I folded the VDPAU_DRIVER_PATH change and adding the -Dvideo-codecs into a single "fix hardware decoding" commit. Would the best way for me to contribute commits the mesa branch be to send it as a series to guix-patches (perhaps prefixed with "[PATCH mesa-branch]" or similar)? <podiki[m]>yes, in light of an official policy I've been thinking that, [PATCH <branch>] or similar <podiki[m]>in this case it'll be mostly us coordinating and is a limited number of patches, so not hard to gather I hope <podiki[m]>thanks for working on this! (i'm often guilty of having a local version for myself and not finishing the polish/sending a patch)