<nckx>bdju: Does it happen with any video codec? Do you have vaapi enabled? Did you ever? Does the previous mpv version run fine on the exact same system (guix time-machine --commit=ba19307af07945fe0e519d3b1a12d3642a73c247)? Everything but the ‘high CPU usage whilst paused’ seems to point at missing acceleration, but that one's strange.
<nckx>For reference, mpv 0.34.1 uses ~5% CPU on this ThinkPad X230T with intel-vaapi-driver.
<bdju>I have vaapi, but not sure it's made much of a difference for me. and I've had it for a little bit now. couple months maybe at least
<bdju>h264 in this case which is gonna be the vast majority of what I watch
<nckx>But you're relatively certain it's the mpv package alone, not something else?
<bdju>h265 is pretty much unplayable for me in most cases. lots of desyncing and frame-dropping. quite possibly a software issue as people with older hardware say they can play the same files fine. but I've never managed to figure it out
<bdju>ah no, not necessarily. I just ran updates recently and saw mpv among the things updating
<nckx>‘people with older hardware say they can play the same files fine’ would probably be me.
<nckx>Within reason, I'm sure 4K 60fps h265 is a bad idea.
<bdju>have seen it from several people. people with newer stuff act clueless and tell me to update my old/bad hardware (which is probably fine), then people with older/weaker CPUs tell me about how they can play the same files okay
<bdju>in my case it's just 1080p anime that's having problems for h265 stuff. so 24fps at most, probably 12 most of the time. but subs and typesetting can affect performance as well
<nckx>CPU usage between .0 and .1 is indentical here.
<lilyp>have you compared mpv to gstreamer by chance?
<bdju>I have not, but for the more recent issue of bad performance while the file is paused, I'm not sure how to recreate that scenario in those other things. not even sure I know how to play a file directly with ffmpeg actually
<kitty1>anyone else have any issues building emacs-haskell-mode? had an issue with it a while back but am trying to figure it out again
<tomog[m]>Hi, I'm reconfiguring my machine local Guix checkout via "./pre-inst-env guix system reconfigure foo.scm". I'd like to pass a channels.scm but this command doesn't have a --channels flag (which is on guix pull instead). Is there a way to get channels working with a local Guix checkout?
<tomog[m]>To clarify, I'd rather not use ~/.config/guix/channels.scm since that has different contents to the file that I want to pass to my "./pre-inst-env ..."i
<tomog[m]>It looks like ./pre-inst-env guix pull --channels foo.scm will work, but that will update my profile's guix.
<tomog[m]>Ah, maybe my best bet at hermeticity-with-channels is guix time-machine, which can point to a local checkout, and supports the --channels flag.
<tangonov>I can't get org roam to install on emacs :/ "linux/falloc.h: No such file or directory" I am guessing this is a hard-coded path issue as gcc is installed and getting so far
***the_tubular71 is now known as the_tubular
<justkdng>hello guys, I'm having issues when installing to bare metal
<justkdng>I like to use ventoy to manage all my isos
<justkdng>but when trying to install guix from ventoy I'm unable to go through the partitioning step
<roptat>avp, fixed. It's the same patch I pushed for java-plexus-component-metadata-1.7, but for java-plexus-component-metadata, should have thought of that before
<roptat>avp, after a "guix pull" it should work again :)
***macrobenis[m] is now known as hachikuji[m]
***hachikuji[m] is now known as macropenis[m]
***rgherdt_ is now known as rgherdt
<foobarxyz>Hi, java packages that produce .jar outputs do not appear to be setting the CLASSPATH variable; if there is a java package A that depends on java package B, how does java package A suppose to find java package B at runtime?
<roptat>you'll have to set it yourself or figure out a patch and send it :)
<foobarxyz>Say a user installs java package A and tries to use the jar file; they will most likely get an exception that a class from package B is misisng, since package B is installed as a dep but is not on the path
<roptat>I understand. I think setting a search-path on icedtea/openjdk would work
<roptat>the CLASSPATH needs to reference files directly, not directories, right?
<foobarxyz>@roptat: thanks, but isn't this a problem with all java packages already? could there be already a recipe in place somewhere?
<roptat>we could also restrict to only lib/m2 and share/java (where we install jar files usually)
<roptat>that would prevent it from finding jar files from the JVM I think, and I don't know if that's a good or a bad thing
<roptat>that would go on icedtea@2, and it should be inherited by all other icedtea/openjdk packages
<foobarxyz>@roptat: thanks, i'll give it a try, what does icedtea@2 refers to? Does it mean this won't be package specific but rather a icedtea definition?
<roptat>yes, you put this on icedtea, it's inherited by icedtea/openjdk packages (all versions), so as long as you have icedtea or openjdk in your environment, the CLASSPATH will be defined for all your packages
<unmatched-paren>foobarxyz: it refers to the package with name "icedtea" and version "2.*"
<foobarxyz>roptat: I've applied the change, but can't see CLASSPATH introduced in the environment ..
<roptat>foobarxyz, how did you create your environment?
<foobarxyz>I haven't, I've made the change and installed a java package from an interactive bash shell using `pre-inst-env guix install`, this has picked up the changes and rebuild all affected changes
<foobarxyz>roptat: my expectation was that after a install a java package from guix source with your changes, the CLASSPATH will appear in my env
<kitzman>this is a long shot, since it's not guix-related, but i'm thinking there are chances someone has encountered a similar problem here.
<kitzman>i'm not running the guix system, just a user profile which sits on top of the distro's system. there is a session bus (managed by guix), pulseaudio (same), and bluez and a system dbus (with the same version) managed by the distro
<kitzman>now bluez doesn't find a2dp - but pulse loaded the bluez module. i suspect the system and session buses are not able to... communicate? if that's ever supposed to happen
<fnstudio>i've created a system image with "guix system image --image-type=qcow2 --save-provenance ...", what extra info am i suppose to find on the new system? i can't see any "/run/current-system/configuration.scm" for instance, is that expected?
<fnstudio>(the reason why i don't get a configuration.scm file might be because i build my image via "guix system image --image-type=qcow2 --save-provenance --load-path=. --expression='(@ (my-oses) base-os)'"
<Gabriel>that is my first time creating a package and doing it as an exercise
<unmatched-paren>Gabriel: you'll need to (arguments (list #:phases #~(modify-phases %standard-phases (delete 'configure))), which will delete the configure build phase and stop it trying to run ./configure
<unmatched-paren>Gabriel: the way it works is that each phase function is invoked like (phase-function #:inputs inputs #:outputs outputs #:make-flags make-flags ...) so when you do lambda* with #:key it allows you to access those keyed parameters, and #:allow-other-keys means you don't have to write them all in the parameter list
<maximed>unmatched-paren: No propagation needed if you add an appropriate 'substitute*' colordiff -> /gnu/store/.../bin/colordiff
<unmatched-paren>(lambda* (#:key outputs) ...) wouldn't work, since guile would raise an error as an unrecognised key was given
<maximed>(Is less fragile than relying on propagation and $PATH -- what if $PATH is not set because it is run directly from /gnu/store/... without putting it in a profile?)
<unmatched-paren>maximed: good point. btw, thanks for reviewing the patchset! (under the reasonable assumption that Maxime Devos is you)
<roptat>justkdng, I don't know too much about how grub installation is implemented in guix exactly, but if you want to prevent it from doing things, I think you need to follow the manual installation steps, the graphical installer won't let you choose the --no-bootloader option
<roptat>(that's the only option I know that affects grub, otherwise you'll have to configure the bootloader declaration in the operating-system record)
<nikola_>I think it's possible to edit config.scm at the end of graphical install, so that it doesn't install grub
<nckx>And has seen little love recently, it seems.
<fnstudio>nckx: brilliant, i see... ok that both confirms some of my understanding and provides more insight - thanks!
<nckx>justkdng: ‘Of course’, provided you correctly configure it to do so. Two caveats I can think of are (1) NVMEs are weird & I don't have any (2) you'll probably have to use the brand new ‘removable’ GRUB variant on UEFI.
<civodul>nckx, rekado: i wonder how long Cuirass can run before we run out of inodes again (3M available currently)
<podiki[m]>since this should now work with more current hardware (modulo as usual linux-libre/firmware requirements, unfortunately)
<macropenis[m]>quick question: how exactly do i pass a decrypted partition to inird? tired of entering my password twice on boot
<nckx>civodul: If berlin has the same distribution of inodes/files as my store, that's about 59 GiB.
<podiki[m]>sneek later tell katco if it was you that wrote about opencl on guix, I hope the rocm update I will submit soon will help, let me know if it does or if you need the bug number (once I submit)
<civodul>would it be possible to use the debbugs ID? :-)
<cbaines>civodul, yeah, that might be something to change at some point
<civodul>it's kind of a detail but that would probably make it more discoverable to many
<cbaines>maybe it can be assumed that new patch series should replace previous patch series when sent to the same bug, so that the branches could be like "issue-DEBBUGS_NUMBER", and just be force pushed to every time the bug is updated
<cbaines>I think the current approach creates multiple branches that map to the same issue, but maybe that's a way around it
<civodul>force-push on every update sounds reasonable to me
<cbaines>I want to try and get back to working on this patch/change review stuff
<cbaines>then surface information about patches there as well
<lechner>Hi, is there a place in Guix that provides package status information beyond the 'master' branch, such as whether a package is in 'staging' or 'core-updates' please? I'd like to make sure I do not provide patches when a something is scheduled for an update already, however delayed. Thanks!
<cbaines>maybe relevant information can also be displayed in Mumi as well
<cbaines> although this is something I've long wanted to do with http://data.qa.guix.gnu.org/ since it has the information on different branches and patches people have sent, there just isn't a way to query it yet
<civodul>cbaines: yeah, Arun is motivated to work on this issue from different angles, IWBN to find a "meeting point" for these approaches
<podiki[m]>anyone know offhand an example of a "source only" package I can look at?
<podiki[m]>(something that doesn't build/install on its own, but used as source in other packages)
<nckx>podiki[m]: Why would that be a package, not an origin?
<nckx>The most complex origin I can think of is probably make-linux-libre-source.
<nckx>First I thought you meant something like restinio, but that still installs things (header files).
<podiki[m]>I would assume (dangerous, I know) that someone would want the rocclr package to use in their own project or package, but it no longer has an install, meant to be included in other projects only
<podiki[m]>so one rocm package needs the rocclr source, which before was a (package-source) which can still work, but rocclr no longer makes sense on its own (you can build it, but there is no "install" in the makefile)
<podiki[m]>I would guess we don't want a package definition that cannot be built on its own
<nckx>Either turn it into a ‘naked’ origin used by other packages in Guix, or, if you want it to remain ‘installable’ from the CLI for devellopeurs, make it install its own source with the copy-build-system (not sure if that's useful, but at least it's not useless).
<nckx>I'm thinking of other hacks like (supported-systems '()) but ew.
<podiki[m]>rocclr also has a few configure-flags needed to build (and the source of another rocm package...) which would be nice maybe for someone to not need to figure out again