IRC channel logs


back to list of logs

*nckx ret.
*unmatched-paren xor rax,rax.
<nckx>Rax, rax, raxputin ♪
<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>This an X200 or something?
<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?
<lilyp>try also ffmpeg for a third metric
<lilyp>oh, no, bdju
<nckx>That makes a lot more sense.
<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
<bdju>ffplay on the same file is not causing the same high cpu usage and temperature
<bdju>however on the issue of h265 playback, ffplay is still choking on a file that mpv had an issue with recently
<bdju>skipping audio in this case. with mpv I think it's the opposite and audio stays mostly fine but video starts to fall behind
<Noisytoot>I've played 1080p 30fps H.265 with mpv on a ThinkPad X200 running Guix System before.
<bdju>it's not all h265, I think it really depends on the particular release, but I definitely have way more problems than with h264
<bdju>oddly ffplay doesn't max my CPU even when it's unable to keep up with playback
<bdju>how do I play something with gstreamer
<bdju>not sure if I have it on my system. gst tab completes to an env var, GST_PLUGIN_PATH=
<unmatched-paren>bdju: it should complete to `gst-inspect`, `gst-launch`, etc
<unmatched-paren>you'll need to do guix shell gstreamer i guess
<justkdng>is intel-media-driver supported under guix?
<justkdng>or is it best to use old hardware?
<justkdng>to use all libre software
<benoitj_>I run the regular kernel, libre-linux is not working with my wifi
<justkdng>it seems all modern hardware requires some sort of binary blob
<benoitj_>there is a compatibility list. it's best to look at that before installing the guix OS
<benoitj_>lot of stuff is compatible, but requires a bit of planning
<benoitj_>otherwise, running guix package manager is another option
<justkdng>it certainly isn't, at least in my case. When I tried the package manager only it ended up breaking Archlinux's build system
<johnjaye>hmm does guix crash if left on for too long?
<johnjaye>this is the second time i left a vm on overnight and it's unresponsive. testing some others to see if i can duplicate
<drakonis>it does not
<drakonis>this sounds like something might be leaking resources
<bjc>my vms do the same thing. i think it's something to do with guix trying to suspend/sleep the vm
<ildar>Please help me. I can't update my Guix because is blocked. connect vpn is not yet possible.
<nckx>ildar: Try <>.
*nckx → 😴💤
<tangonov>I am noticing "chrome-gnome-shell" isn't a thing on the Guix System yet. People seem to be packaging extensions separately. Is making/contributing an extension package the way to go?
<tangonov>Specifically would like to install/maintain - I suppose I can install this manually without a package but I'm interested in the "Guix" way
<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
<justkdng>is ventoy not supported?
<efraim>hello guix!
<lilyp>sneek later tell tangonov packaging gnome extensions is comparatively easy. Most often you just have to move some Javascript to the correct location using copy-build-system
<avp>Hello Guixers! FWIW, Guix fails to build 'maven-filtering' (tests are failing):
<roptat>avp, indeed, I'll have a look
<roptat>ah, again "generate-metadata" is failing
<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>foobarxyz, yeah CLASSPATH is not set
<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>no there's nothing right now
<foobarxyz>roptat: right, CLASSPATH has to reference the jar file directly
<roptat>ok, let me figure out how to do that in a search-path specification
<roptat>currently, we wrap the scripts for the few java programs we packaged, so josm, maven, etc can be executed
<foobarxyz>roptat: thanks search-paths seems the right way to go, though there isn't much in the manual on how to specify one
<roptat>found it :)
<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.*"
<unmatched-paren>which is probably called icedtea-2 in scheme
<roptat>I think it's called icedtea-7 :/
<unmatched-paren>of course it is.
<unmatched-paren>(why is it called icedtea-7?)
<roptat>because icedtea@2 is for java 7
<foobarxyz>roptat: i see thanks, this would also be inherited by icedtea@3 (icedtea-8), which is my main target. I target icedtea-8 jars that end up in share/java in my case
<roptat>foobarxyz, I'm testing a change and
<roptat>and will send a patch if it seems to work
<roptat>it'll involve rebuilding all of our java packages, so it can't go to master I think
<foobarxyz>roptat: great thanks, in the meantime i'm just running the snippet you have send to see the end effect
<roptat>I don't think it can hurt because ant-build-system redefines CLASSPATH, but maybe we can drop that phase while we're changing everything in java
<roptat>I would use (files '("lib/m2" "share/java")) instead of (files '(""))
<jpoiret>sneek, later tell tomog[m]: you can use -L with all guix commands to temporarily add channels (or at least their packages/scripts)
<vier-littleme>how to enter the single user by grub at guixsd?
<vier-littleme>i fucked up with /etc/pam file, even root can't login now
<roptat>I don't think there's a single-user mode in guix system
<roptat>you cloud try init=/bin/sh
<vier-littleme>roptat: it seems guixsd didn't accept init too
<roptat>also, it's called "the Guix System" now ;)
<vier-littleme>but i found the /gnu/store/uuid-xxx-init exists at my other guix system
<roptat>you mean it crashed, or you mean it didn't have any effect?
<vier-littleme>roptat: maybe i can call it GS, lol
<vier-littleme>roptat: no effect, i mean
<roptat>mh, then I don't know how to help you
<unmatched-paren>i guess you could try mounting inside a live usb and repairing it?
<unmatched-paren>if that's possible?
<vier-littleme>yeah, i have to find a flash driver now, i don't have other good idea beside this
<unmatched-paren>vier-littleme: did you manually modify the /etc/pam file, or did you change it via guix?
<unmatched-paren>*guix services
<vier-littleme>a dear rm /etc/pam* -rf, i mean
<unmatched-paren>ah, could have been worse. you could have accidentally put a space between / and etc.
<vier-littleme>oh no!!!!
<vier-littleme>not that again
*unmatched-paren realizes that they'd have to have provided --no-preserve-root to do that
*vier-littleme crying
<Haider>I just broke my pc :(
<Haider>doesnt matter, time to fix it
<vier-littleme>good news, /etc alive, bad news no flashdriver found-\
<vier-littleme>it must contain some argument that kernal lead the init
<vier-littleme>or maybe i could make some error let's kernal fallback into guile
<unmatched-paren>there must be some parameter that forces boot-to-guile...
<vier-littleme>kill the system argument
<vier-littleme>now fallback into guile now
<vier-littleme>victory is ahead
<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
<fnstudio>sorry, i was disconnected for a bit
<fnstudio>is getconf available under guix, a package search would seem to imply that it does not
<ildar>Hi. sorry, how to use instructions?
<foobarxyz>roptat: thanks for your help so far, I need to go; did you say you are going to consider a patch for this on master?
<roptat>foobarxyz, yes I'll send a patch. it worked for me, you probably have to reinstall icedtea for the search-path to be taken into account
<foobarxyz>roptat: ok will do that thanks
<fnstudio>ah, i found the answer to my tramp-related issues! here:
<ildar>sorry, how can i add a mirror?
<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
<civodul>hey there!
<civodul>we're getting ENOSPC on berlin but there's plenty of space
*civodul stops cuirass
<rekado>how come?
<rekado>21T free on /gnu, 1.5T elsewhere
<roptat>civodul, inodes?
<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 first half of my question is answered here
<fnstudio>i'd still be keen to know your thoughts on the configuration.scm file
<civodul>roptat, rekado: could it be inodes?
<civodul>i don't see any clues
<civodul>maybe yes after all:
<civodul>$ df -hi /gnu/store
<civodul>Filesystem Inodes IUsed IFree IUse% Mounted on
<civodul>/dev/sdh1 582M 582M 0 100% /gnu/store
<civodul>what do we do?
<efraim>what's supposed to be mounted there?
*civodul tries "guix gc -C20G" for a start
<civodul>efraim: it's ext4
<efraim>doh, I saw the inodes part and still saw the 582M and decided that it was the size of the directory, no the number of inodes
<fnstudio>(oh ok, it might be explained here, in the caveats section )
<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)'"
<fnstudio>i thought i was being smart in using an expression but that might actually have quite serious drawbacks
<Gabriel>hi everyone, getting ".configure not found" error when trying to build my custom package
<Gabriel>any idea?
<lilyp>is that ".configure", not "./configure" or "configure"?
<Gabriel>"./configure: No such file or directory"
<Gabriel>when running build -m ./my-package.scm
<unmatched-paren>Gabriel: you'll need to delete the 'configure phase
<unmatched-paren>this package uses a standalone makefile, right?
<unmatched-paren>gnu-build-system assumes the use of the autotools, so it runs ./configure before building
<Gabriel>I'm creating a package based on the follow repo: and yeah there is a Makefile
<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>you'll need to import (guix gexp) too
<Gabriel>unmatched-paren: it passed through and now it is failing when trying to install: "No rule to make target install"
<unmatched-paren>Gabriel: looks like you'll need to manually install the output; that makefile doesn't provide installation.
<unmatched-paren>Gabriel: inside that modify-phases, you can add this
<unmatched-paren>(replace 'install (lambda* (#:key outputs #:allow-other-keys)
<unmatched-paren> (let ((out (assoc-ref outputs "out")))
<unmatched-paren> (install-file "foo" (string-append out "/bin"))
<unmatched-paren>that replaces the install phase with one that gets the output store path and installs "foo" into the output's bin directory
<unmatched-paren>replace foo with pstree or whatever, ofc :)
<unmatched-paren>and add the missing parens.
<Gabriel>should package remove also be done similarly?
<unmatched-paren>Gabriel: what do you mean by package remove?
<Gabriel>> guix remove pstree
<unmatched-paren>you don't need to do anything to make package removal work
<unmatched-paren>it Just Works
<unmatched-paren>(by removing that package's output from your profile)
<Gabriel>aaah got it
<unmatched-paren>(assoc-ref foo "bar"), assuming foo looks like '(("bar" . 32) ("baz" . 88)), will return 32. it's basically the alist lookup function.
<unmatched-paren>the package outputs are stored as an alist:
<unmatched-paren>'(("out" . "/gnu/store/...") ("doc" . "/gnu/store/...") ("static" . "/gnu/store/..."))
<unmatched-paren>out is the output you usually want
<vier-littleme>ok i totally fuck up~, let's reinstall system
<unmatched-paren>aerc invokes colordiff; should its package include it as a propagated-input? guessing no.
<Gabriel>unmatched-paren: wooww. Thank you very much!!!!
<Gabriel>it worked and I learned some nice tricks, thank you bro
<unmatched-paren>Gabriel: you can also do (add-before 'phase 'new-phase (lambda* (...) ...)) and likewise with add-after :) in case you ever need to add phases
<unmatched-paren>also, if you don't need the outputs, inputs, etc you can just use (lambda _ ...) instead of (lambda* (...) ...)
<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)
<unmatched-paren>i've responded to all the emails now, i think.
<Gabriel>are these key parameters a Scheme's feature?
<lilyp>we call them arguments here
<unmatched-paren>Gabriel: a feature of Guile, specifically. probably most schemes provide them in some form though.
<lilyp>it's a guile feature, but i wouldn't be surprised if it's in other schemes too
<unmatched-paren>e.g. s7 provides them with :ident
<reyman>Hi !
<Gabriel>nice! I have a lot to learn hehehe just started my journey this weekend. hope to again chat to you soon...
<reyman>Is it possible to have more information about line that failed to debug some package dependencies ?
<roptat>reyman, what's the context?
<lilyp>the failing package is reported by to stderr, you can use -K to keep the build directory
<lilyp>s/by to/to/
<reyman>i try to adapt dominicm guix home dotfile, but i miss something, the %dm/home-packages return "variable not linked"
<reyman>i push my dotfile somewhere and i push link here
<unmatched-paren>Gabriel: lambda*, define* etc (with the asterisks) allow you to define keyed arguments. regular define and lambda don't
<unmatched-paren>if you pass a key to a regular define/lambda, it'll just be passed literally
<unmatched-paren>(define (foo bar) bar) (foo #:bar) returns #:bar
<unmatched-paren>which is why (lambda _ ...) works; it'll just take the keyword literally and ignore it
<unmatched-paren>how can i force a package to be built when it's already in the store?
<maximed>unmatched-paren: --check
<maximed>guix build --check
<maximed>It's technically for checking reproducibility but it has the right effect
<unmatched-paren>maximed: doesn't seem to work either, just prints a store path
<maximed>(it does not replace the old store item, only builds it again!)
<unmatched-paren>oh, nvm, it does
<maximed>unmatched-paren: Due to technical reasons, maybe "guix build --no-grafts the-package"
<maximed>(grafts can sometimes interfere here due to $reasons)
<roptat>--no-grafts --check even ;)
<reyman>Sorry for the delay, i push my attempt of guix home config here :
<reyman>and i run guix home -L . reconfigure machines/suhayl-home.scm
<reyman>and that fail because %dm/home-packages from base/home.scm is not recognized, i don't understand why
<civodul>efraim, rekado: GC's running, no ETA, but i'm afraid it's gonna take long
<civodul>is there a tune2fs knob we should tweak?
<civodul>(how that inode limit can still be a thing in 2022?)
*unmatched-paren afk
<reyman>if you have 5min to look my dotfile attempt @roptat i'm interested, i suppose this is linked to my module comprehension :)
<reyman>module need to be builded alone before using ?
<Gabriel>what to do when we have a binary file trying to execute a program within /bin, for example "/bin/rm" ? - I'm trying to install VBoxLinuxAdditions...
*unmatched-paren back
<tribals>Hi, folks!
<tribals>Is there a way to avoid doing `$ make` each time after switching git branch? Personally I use git branches a lot.
<reyman>finally i found a way to debug my scm script, using the guix repl -L /home/reyman/src/guix-config/
<reyman>then loading module ,use (base home)
<reyman>return errors that guix home reconfigure doesn't return
<reyman>now that work \o/ !
<justkdng>hello again everyone, I tried to install guix yesterday but sadly was unable to
<justkdng>is there a way to prevent grub from touching efivars?
<justkdng>it seems my bios is broken and efibootmgr doesn't work
<justkdng>and during installation it fails during the last steps I believe
<justkdng>with an I/O error
<roptat>reyman, sorry I was away :/
<roptat>glad that you fixed your issues :)
<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
<sneek>nckx: Greetings :)
<nckx>sneek: botsnack
<justkdng>so, I could set up an empty bootloader?
<justkdng>how could I do that?
<justkdng>just removing the bootloader part of config.scm doesn't work
<nckx>(bootloader … (installer #~(const #t)))
<acrow>nckx: nifty bootloader tip! Finding 2019 discussion in less than two minutes for repost -- way cool.
<nckx>I cheated by knowing the answer, which makes it much easier to search for examples… 😉 but thanks.
<nckx>More official source: but there doesn't seem to be a cookbook entry for this FAQ.
<nckx>justkdng: To answer your earlier question: no, I don't think Ventoy supports Guix. You're not the first to report it not working I'm afraid.
<Michal_Atlas[m]>Hi, how do you setup your emacs with guix home?
<Michal_Atlas[m]>I've been using the home-files-service to place an init.el file, but Emacs really likes writing to it and generates a large number of errors and prompts if it's read-only.
<Michal_Atlas[m]>what's the workaround?
<nckx>justkdng: Seems to be a classic loopback system, which requires the distro to ‘know’ it's running from a file, and do some extra work. Guix doesn't.
*rekado just pushed wip-postfix
<jpoiret>Michal_Atlas[m]: does emacs really like to write to the init file all the time? except for customize, i'm not sure that'd be the case
<PotentialUser-60>i managed to build a package out of a customized version in guix using pre-inst-inv however i'm unable to install it using a regular user or use it during system reconfigure
<jpoiret>PotentialUser-60: you'd need to use ./pre-inst-env guix package -i or ./pre-inst-env guix system reconfigure (if that's not what you're trying)
<Michal_Atlas[m]>I use some org stuff, which is not well behaved and emacs writes package-selected-packages and an empty custom-set-faces
<jpoiret>arf, i'd suggest using some declarative alternatives to packages.el
<Michal_Atlas[m]>Well, I am, guix
<justkdng>ok, ty for the grub tip
<justkdng>that being said, is it normal for guix to be compiled when reconfiguring/pulling ?
<justkdng>I tried installing in a celeron laptop and it takes really long
<avp>roptat: Thanks, now it builds correctly.
<nckx>justkdng: When pulling: yes, and if the pull updated anything used by reconfigure: also yes.
<nckx>Guix is not Celeron-friendly ☹
*nckx used Guix on an ‘AMD APU’ for a while, it was hell.
<fnstudio>hey i was wondering what can be the advantage of using guix deploy as opposed to SCPing the system configuration file onto the remote machine and then launching a reconfigure from there?
<fnstudio>something that comes to mind is the fact that, with guix deploy, the substitutes get built on the coordinator machine, which is possibly more powerful
<fnstudio>is that correct? (other that the fact that this is of course very dependant on circumstances)
<fnstudio>having to type one single command (as opposed to SCP-copying a file, logging onto the machine, launching the reconfig) is also an advantage
<nckx>If you're using it to deploy a single new machine, that's probably the most significant difference, yes. That and mild convenience if you're not spinning up machines every Tuesday.
<justkdng>nckx: is that so?
<justkdng>I have another laptop but I'm not ready to switch my current setup to guix
<justkdng>can I run guix from an extern nvme?
<nckx>fnstudio: The real goal of ‘guix deploy’ is to deploy multiple interdependent systems at once.
<nckx>‘goal’ because it's still in development.
<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.
<nckx>But in principle, absolutely.
<the_tubular>nckx can you check your dm when you got a second ?
<nckx>Good thing you asked.
<nckx>PSA that I never see PMs.
<the_tubular>I noticed :P
<unmatched-paren>hmm. seems like GOOS and GOARCH aren't set in the go-build-system.
<justkdng>'removable' efi grub?
<justkdng>does it need special config?
<unmatched-paren>that's annoying, since i need to run this during a build
<unmatched-paren>how do i get the target architecture again?
<unmatched-paren>aha, `go tool dist env` prints GOOS, GOARCH, etc
<fnstudio>if i build an image via `guix system image ... --save-provenance --expression=<my-os>', the image gets created and it boots fine but it won't include a `/run/current-system/configuration.scm' file (which is expected and documented here )
<fnstudio>however, if i drop the idea of using `--expression' and simply use a configuration.scm to start with, i might end up with quite a bit of duplication in my files
<fnstudio>or maybe not, if i only use guix system image to build the base os image
<fnstudio>sorry, not a question, it was me thinking out loud (and wasting your bandwidth)
<unmatched-paren>ah, current-target-system, i remember now :)
<podiki[m]>anyone here use rocm? (amd opencl stuff)
<justkdng>I use it under arch
<podiki[m]>I have some local updates for it that I think work (tried it with darktable)
<podiki[m]>it has been a little so I need to go through and prepare them as proper patches, if you wanted to test under guix I can give you a headsup when I get them submitted
<f1refly>guix substitute ci server seems to fail, is this my fault or the servers fault?
<podiki[m]>seems up to me, try again?
<f1refly>I did, same result
<podiki[m]> I guess on your end then, was downloading subs for me right now
<podiki[m]>was there some change to making the docs? trying to just do a make in a checkout I get a lot of ./doc/ @ref reference to nonexistent node
<f1refly>weird, I have no idea what could go wrong :
<podiki[m]>f1refly: can you load the frontend webpage?
<f1refly>I get a bad gateway in the browser as well
<podiki[m]>that link is 502 for me too
<f1refly>but yes, I can load the main welcome site and other substitutes work as well
<podiki[m]>maybe that's an old (gc-ed) hash?
<podiki[m]>ah, so something with that particular derivation
<f1refly>yeah, maybe my guix is just too old
<podiki[m]>how old? though I would think it would just not find the sub and build locally?
<podiki[m]>or I guess the CI still has a record of that derivation but not the file? I don't know enough of how that works, sorry
<f1refly>When the derivation fails to download with a 502 error the local build isn't tried even with --fallback
<f1refly>getting another 502 for a fresh pull
<f1refly>for this time
<podiki[m]>that page is 502 (maybe that's always true for those nar/ pages?)
<podiki[m]>but guix shell font-termsyn downloads a sub and works fine
<podiki[m]>so maybe some internet or route flakiness on your end?
<podiki[m]>the hash is /gnu/store/izj8mzdccblwbxdavi5svfm6ar678sm6-font-termsyn-1.8.7
<f1refly>idk what to do about that yeah I'm getting a 502 for
<rekado>I also got some bad substitutes
<rekado>maybe related to that inode ENOSPC
<f1refly>I'll try to fall back to --no-substitutes and hope the packages can be built before I'm running out of time
<f1refly>it's just some python deps and subversion apparently
<f1refly>fingers crossed
<rekado>civodul: are you running a special “guix publish” process on berlin?
<podiki[m]>meanwhile I'm still stuck on make failing with lots of "reference to nonexistent node" in doc/
<podiki[m]>something with my checkout, as a fresh one works, but I tried all the make clean and don't have local changes :-/
<podiki[m]>okay think I fixed it! removed all the contributing.*.texi documents (just contributing.texi left) and redid the bootstrap/configure
*rekado restarted cuirass, cuirass-web, nginx, guix-publish on berlin
<rekado>f1refly: can you please try again?
<f1refly>works now rekado
<f1refly>thanks a lot :)
<unmatched-paren>is %current-{,target-}system a GCC triplet or Nix system?
*avp is slowly working on adding this to Guix:
<nckx>unmatched-paren: Depends on the {} part :) -target- triplet butfg %current-(Nix )system, just like the CLI options.
<civodul>avp: hey, neat
<civodul>rekado: no, i'm not running 'guix publish' there
<civodul>is there a stale process or something?
<nckx>There was.
<avp>I've sent an update for 'java-commons-lang3' to the ML:
<nckx>It was enabled & stopped.
*civodul checks backlog
<nckx>I don't think it's in the backlog.
<nckx>rekado rudely fixed it whilst I was debugging it.
<nckx>So we probably stepped all over each other's toes.
<nckx>unmatched-paren: That ‘fg’ was for my shell, not for you.
<podiki[m]>if anyone is familiar with rocm and llvm-for-rocm, does that all need to be in one patch to update?
<podiki[m]>rocm.scm notes that all the packages must be updated together (common version), llvm-for-rocm could be done first in a separate commit?
<podiki[m]>(also: hooray, llvm-for-rocm finished building successfully)
<civodul>nckx: i was afk, so that's okay :-)
<nckx>podiki[m]: That comment isn't gospel, and llvm-for isn't in that file anyway, and if the old rocm still compiles with the newer llvm, I would vote separate.
<podiki[m]>nckx: I did find that at least a good chunk of the rocm packages depend on each other in ways that I just updated all their hashes :)
<nckx>And that's what that comment is about, I think.
<podiki[m]>as for llvm-for-rocm I think it needed to be updated, or at least was easier to update it to the latest llvm (I tweaked the patches)
<podiki[m]>but, yes, think I can make that first commit (llvm-for update) and then one commit with all rocm updates (mostly hashes, some build/patch tweaks)
<nckx>'s What I'd do. 🤷
<podiki[m]>works for me :)
<podiki[m]>alright, with that I think I get opencl in darktable!
<podiki[m]>I think this might also help for that thread and blog post some time back about opencl on guix and some roadblocks
<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)
<sneek>Got it.
<podiki[m]>sneek botsnack
<civodul>nckx: i suspect it has many more small files than a user's store, .drv files for all the architectures in particular
<nckx>I don't think it's possible to avoid the double password prompt without maintaining an unencrypted /boot (which is currently a manual task not handled by Guix).
<civodul>ah but Cuirass is waiting for the GC lock anyway
<nckx>civodul: I build a lot from source, but true.
<nckx>civodul: Let's leave it running for once?
<nckx>Or does that really take forever?
***macropenis[m] is now known as macroperson[m]
<macroperson[m]>small update to a more professional name
<nckx>We're all professionals here 👔
<macroperson[m]>honestly forgot i changed my nick to that
<nckx>Unfortunately I don't have a better answer for your new & improved nick.
*podiki[m] goes to build llvm again, as a patch was updated with a comment...
<nckx>(Scheme) comments should not affect hashes?
<macroperson[m]>ah no worries :) going over the manual again to find any mentions
<nckx>That's the problem, I don't think it's documented. Without writing any extra code, Guix currently can't do better than 2 prompts, I think.
<podiki[m]>a comment in the patch file, forgot to give credit to the source (gentoo)
<nckx>Ah, a patch-patch, never mind.
<podiki[m]>it is clearly not warm enough here for June, so gotta help it along
<nckx>macroperson[m]: Coincidentally there was a resurgence of interest in that a few days ago:
<macroperson[m]>ah, I will keep tabs on this then
<justkdng>would you guys accept a systemd-boot package? just contaning bootctl binaries and efi files
<nckx>podiki[m]: gUiX iS bOiLiNg ThE OcEaNs
<nckx>justkdng: Sure, if it's all built from (free) source.
<justkdng>nice, surprised there isn't one
*nckx 's ‘code's done compiling’, back to work.
<civodul>uh the cairomm update on master forces me to do another master->staging merge to get things built
<civodul>hmm or does it?
<civodul>nckx: actually e31ab8c24848a7691a838af8df61d3e7097cddbc caused a rebuild of 2K packages
<civodul>(the dependents of cairomm@1.14)
<civodul>due to the label change
<civodul>no big deal, but i'll get it built on staging first
<nckx>No? I can revert it if it's inopportune.
<civodul>too late :-)
<civodul>that's okay, we'll delay the staging merge a tiny little bit more
<nckx>I tried to make ‘guix refresh’ inheritance-aware a few years ago. It went very poorly because I had no idea what I was doing. Maybe I should give it another go.
*nckx implying they have an idea now.
<civodul>that "guix build libreoffice -n" test is a must!
<nckx>It's bitten me too often (it does not, in fact, depend on everything — we should file a bug report about that).
<justkdng>>rebuild of 2k packages
<justkdng>oh no
<civodul>justkdng: you didn't notice, the build farm built it all in the meantime :-)
<civodul>nckx: it's tricky because "inheritance" is purely syntactic
<rekado>this inode thing is ridiculous
<civodul>isn't it?
<rekado>and yes, gc will take a long time because … we still use that big ol’ store on the big ol’ storage.
<civodul>i'm surprised such a problem even exists in 2022
<civodul>right, so it's a good time to start setting up that machine, as you pointed out earlier on guix-sysadmin
<nckx>ext4 was a deliberately small leap. At least that's how they spun it.
<nckx>Btrfs was very busy being the future of file systems back then.
<civodul>i found a couple of posts on the net saying one can change the inode/data ratio when making the file system
<civodul>but that's really not something i want to care about
<nckx>Only then.
<nckx>The preset is/was called ‘mail’ because why else would you want lots of inodes.
<civodul>since the new storage is attached to berlin, should we try and make that file system now?
<civodul>well, "now"
<cbaines>I'm hoping the patch review stuff can help figure out the effect of changes (in terms of package rebuilds)
<nckx>Speaking of powerpc64le-linux (on the ML), is guixp9 no longer used?
<justkdng>phew, so I don't have to build that much packages
<cbaines>even now, the information is on (assuming it's processed the patch series), it just needs to be exposed better
<justkdng>thought guix was like gentoo for a while there
<nckx>cbaines: Absolutely, and that's a good robust feature to have, but it shouldn't™ require such a heavy method to see what touches what.
<nckx>You shouldn't have to diff all-the-derivations.20k.txt
<civodul>cbaines: re staging, the link you gave on the list was very useful to me
<civodul>(to find regressions)
<cbaines>civodul, that's good to hear, I'm hoping to make some progress in making that data more available
<civodul>right, finding the link is the tricky part ;-)
<civodul>cbaines: re, how can one map "series-XYZ" to a debbugs issue number or similar?
<civodul>and vice-versa
<cbaines>civodul, via, as the XYZ in series-XYZ is the Patchwork series ID
<cbaines>the Patchwork pages for the patches in that series should contain links to
<civodul>oh, i see
<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>my current thinking is to try and make a thing, with some of the ideas discussed ages ago
<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>lechner, not that I'm aware of
<arescorpio> $ wget -c , run and not problem version 1.3.0 ( use in terminal)
<cbaines> although this is something I've long wanted to do with 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
<podiki[m]>oh, I guess one configure flag is used in a package that needs rocclr, so that serves as an example for usage
<podiki[m]>(the other flag is more standard, a -DCMAKE_INSTALL_PREFIX)
<nckx>So it has a mandatory configure flag that isn't implicitly set? What a weird package.