IRC channel logs


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)) ...)
<TristanCottam[m]>Michal_Atlas: Are there any drawbacks?
<mirai>am I missing something?
<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
<TristanCottam[m]>But I gotta go now, see you all later
<bjc>well well well. look who's back for more
<apteryx>nckx: o.O welcome back!
<rekado>yay, nckx is back!
<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
<nckx>Hey all :)
<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?
<Michal_Atlas[m]>yayyyy \o/
<rekado>sughosha: are there logs?
<sughosha>rekado: I don't know about btest_lto.
<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!
<nckx>Did I?
<nckx>‘Oops.’ o/
<gnucode>is there a way to tell guix to try to install a package, even though "make check" fails?
<sughosha>rekado: I updated libbacktrace to the latest available version, now it is fine. I also sent my patch here:
<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 directly ?
<gnucode>ben-7549: sounds about right.
<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
<gnucode>ben-7549: sounds good.
<kaelyn>While testing some VDPAU changes, I've discovered that the recent core-updates merge--and I believe specifically the mesa update--have introduced a functional regression with hardware decoding. Using a download of (an h264 encoded file), "mpv --hwdec=auto ~/27-poiret.mp4" has working hardware decoding with mesa 21.3.8, but with mesa 22.2.4
<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
<civodul>so 'symbol?' returns #false
<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]>awesome, thanks in advance!
<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)
<kaelyn>you're welcome!
<podiki[m]>kaelyn: ah, I had this open already in a tab (that's why I keep so many...):