IRC channel logs


back to list of logs

<Kolev>Does anyone have a solution to my audio issue, or should I just go back to a foreign distro?
<rekado>Kolev: you didn’t provide any details about the kind of problem you’re seeing, so it’s hard to help.
<Kolev>rekado, I don't know how to provide details.
<mekeor>Kolev: is it possible that copy- and pasting code (from the conf-packages that you attached to the email) into alsa-configuration for alsa-service would work?
<mekeor>ACTION is happy about how easy it was to manually build idris2 with guix
<apteryx>rekado: ah! i'm struggling with CSS because we load some lib called pico that does its own styling
<apteryx>ACTION wonders if there's a way to reset styling for a specific element
<apteryx>to undo all of what pico does
<apteryx>rekado: phew, finally nailed the CSS right
<apteryx>using a flex container row
<rekado>apteryx: pico is a glorified reset CSS.
<civodul>Hello Guix!
<futurile>Morning civodul
<efraim>hacking on debian packaging isn't something I do often enough to actually remember what to do
<efraim>I'm trying to fix guile-git-0.5 on debian for powerpc so I can see if guix-1.4.0 will build there so I can just install it on my other ibook g4
<efraim>and I can't seem to get my patches to apply
<efraim>unrelated, librsvg fails its test suite if the machine is too busy, makes we want to write (or (apply (... 'check)) (apply (... 'check))) for the 'check phase
<futurile>Heh maybe you can slip a new packaging approach past a Debian maintainer ;-)
<efraim>for the curious, building the guix 1.4.0 package on debian on my ppc machine takes about 18 hours
<efraim>guile-git is only about 30 minutes, so if I manage to get my patch to apply there I'll have figured out what do to for the guix package
<civodul>efraim: it fails its tests due to timeouts?
<efraim>civodul: the guile-git tests fails on the same on on powerpc-linux that we have disabled in guix
<efraim>the guix package fails on some tests in tests/channels.scm, but it might be due to the version of guile-git I have on that machine
<efraim>TIL lesspipe on debian is an actual shell script debian maintains
<attila_lendvai>mekeor, i've made a full bootstrap of idris2 (they rejected it), and the guix side:
<peanuts>"[ build ] A major refactor of the build system by attila-lendvai ? Pull Request #1990 ? idris-lang/Idris2 ? GitHub"
<peanuts>"[PATCH] gnu: Add Idris 2."
<apteryx>efraim: 18 h! haha
<efraim>not as bad as other ones I've worked on but certainly frusterating
<zenmaya>is there a way to create environment variables in a manifest? I want to add a LD_LIBRARY_PATH for the development of my package, however this is not something automatically set
<zenmaya>attila_lendvai: this is really cool! <3
<janneke>yay, core-updates starts to produce results
<efraim>are we working on core-updates for the next merge?
<attila_lendvai>zenmaya, i thought that, too. it was fun to work on it, but i was rather dismayed by the maintainers' lack of enthusiasm.
<peanuts>"An update on ???core-updates???"
<civodul>janneke, efraim: neat! i haven’t been able to follow, but i hope “we” can work on merging soon
<civodul>i was hoping someone could take the lead :-)
<apteryx>I think jpoiret had volunteered :-)
<efraim>let's tell them to send the email to guix-patches to get qa started building the branch!
<apteryx>and I sure volunteer to fix any breakage introduced by merging most core-updates patches found on our tracker
<apteryx>ACTION is looking at updating imagemagick to 6.9.13-5, which fixes CVEs
<apteryx>the gold-as-ld-wrapper thing is broken too, not sure why
<jpoiret>apteryx: maybe it wasn't too clear from my message :)
<jpoiret>i've got gnome building locally, but the whole system image is proving problematic because of crypsetup-static, see #68656 (i'd like to have ideas/reviews on that one)
<peanuts>"[PATCH core-updates 0/7] Cryptsetup woes"
<civodul>jpoiret: oh, excellent! (apologies, i haven’t followed guix-devel lately)
<cdo256`>Is the derivation format (.drv files) considered private to the daemon?
<civodul>cdo256`: not really, but you should access it only via (guix derivations)
<apteryx>where did mirai go?
<efraim>sneek: seen mirai
<sneek>mekeor was last seen in #guix 14 hours ago, saying: Kolev: is it possible that copy- and pasting code (from the conf-packages that you attached to the email) into alsa-configuration for alsa-service would work?.
<efraim>sneek: botsnack
<apteryx>sneek: you confuse mirai with mekeor
<apteryx>sneek: -botsnack
<cdo256`>civodul: Got it. Glad I asked :)
<janneke>wow, the new pretty-printed builders are nice
<ulfvonbelow>ooo, is guix-scheme-mode finally unnecessary?
<apteryx>janneke: that's great! didn't know about that change
<janneke>ACTION wonders about the incredible rate at which x86_64-linux packages for core-updates are built, and likewise puzzled about the abominably low rate at with i686-linux packages are built?
<janneke>apteryx: yeah, /me wants that for /etc/guix/machines.scm (and any other such file) too :)
<civodul>pretty-printed builders?
<civodul>isn’t it taking a lot of space?
<janneke>lots of space!
<janneke>wc $(./pre-inst-env guix build -d hello; cd ../core-updates && ./pre-inst-env guix build -d hello)
<janneke> 0 8 1300 /gnu/store/qr00sgbh3vwwqswmgjjymg6wkys9r4i2-hello-2.12.1.drv
<janneke> 0 1 2292 /gnu/store/fb3d6ps4v696xrrj6ci3dq6rlci9dnbi-hello-2.12.1.drv
<janneke> 0 9 3592 total
<janneke>i guess we'll just have to write more efficient build recipes
<civodul>ok, that’s an overstatement :-)
<civodul>you’re looking at the .drv though, not the *-builder thing, right?
<ulfvonbelow>wait, how did pretty-printing the builders manage to increase the size of the derivation itself?
<janneke>oh wait yeah, that's the drv
<civodul>also, that of libreoffice is likely bigger than that of hello
<rekado>ACTION patiently waits for the introduction of .drv.gz, then .drv.xz, and finally .drv.zstd
<civodul>an old goal of mine is to arrange to have a single builder for gnu-build-system (say) and have it parameterized by environment variables and/or command-line arguments
<civodul>that’d means fewer store RPCs and fewer files in the store
<civodul>it’s surprisingly tricky though
<jpoiret>no one builds packages themselves tho, right?
<ulfvonbelow>ACTION exclusively builds packages himself
<civodul>oh yes, that’s another thing with larger builders: RPCs are going to send more data, which takes more time, esp. with remote stores
<apteryx>could the data sent be compressed on the fly?
<ulfvonbelow>if we're allowed to cheat, we could just embed the builder string itself in the derivation command-line using guile's -c flag
<jpoiret>then drvs get bigger?
<ulfvonbelow>it'd be fewer inodes, but aside from that not much less in total size requirements
<civodul>apteryx: not really: compatibility reasons, plus it’d be too expensive
<civodul>i feel like the grumpy old guy because i totally missed those discussions earlier :-)
<civodul>my preference would have been to have a command to read and pretty-print builders (and derivations)
<civodul>yeah also “guix build -d libreoffice” is prolly going to take more CPU time with pretty-printing
<civodul>also! the pretty-printer doesn’t provide a “canonical form” (unlike ‘write’)
<civodul>its output changes following fashion and all
<rekado>hmm, the jobset for the “master” branch on is a little behind
<rekado>it only just got the change to commit 9b65b60.
<rekado>but that’s a day ago
<rekado>I always pretty-printed builders on demand with Emacs
<rekado>it’s not often that I have to read them, though
<rekado>only for exceptional debugging cases
<ulfvonbelow>I guess one situation where the stuff being pretty-printed in the file itself is useful is if you're stuck in a rescue repl in early-boot, trying to read /init and its dependencies
<apteryx>same, but I doubt the 1 byte per newline increase in a builder file will cause much difference
<apteryx>was it profiled at the time it was added?
<apteryx>ACTION this feels like minifed js
<ulfvonbelow>1 byte per newline plus a space for every level of indentation
<rekado>ulfvonbelow: I think in a situation like this we’d rather want a better rescue repl
<ulfvonbelow>well, at *least* one space per level of nesting, if it's following conventions for various forms, it's going to be even more
<apteryx>civodul: or drv.zst as hinted by rekado :-)
<ulfvonbelow>it does feel a little wasteful to list all the input paths in the builder itself when they can already all be found within two layers of reading derivations, but I suppose exploiting that would require the derivation itself to be available at build-time
<ulfvonbelow>the inputs are the main thing (aside from some arguments like #:phases, #:tests?, etc) that changes between different packages of the same build-system, right?
<civodul>ulfvonbelow: yes, exactly
<civodul>there’s already a single builder for things like downloads
<civodul>that’s the exception, but we should try to make it the norm
<civodul>for the next ‘core-updates’ cycle anyway :-)
<rekado>is it just me or has librsvg been touched, leading to a rebuild of all GTK, Java, etc stuff?
<jpoiret>on c-u?
<rekado>on the master branch
<rekado>“guix weather” says there are no substitutes for gtk+
<rekado>also no icedtea substitutes
<efraim>we had an emacs kerfuffle where emacs-minimal got bumped and then reverted
<rekado>commit 0afe456973e8d5d51ea23c41579b94bde99d08d8, but I’m way past that commit
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<efraim>gah, it was me. source-highlight is load bearing
<rekado>probably 367bc2d198f57bc34522441820f761b61fed0ce0
<peanuts>"guix.git - GNU Guix and GNU Guix System"
<efraim>ok, it's been reverted
<efraim> cuirass seems to be lagging behind
<rekado>yes, it’s a day behind
<rekado>weird, that
<rekado>the graph for evaluation speed doesn’t show any abnormality here
<civodul>what’s prolly happening is that there are too many evaluations being queued
<civodul>there’s a maximum of 8 concurrent evaluations
<civodul>if some of them are taking a very long time (like on core-updates), the use one slot for all that duration
<efraim>it's set to queue every 5 minutes on master?
<civodul>there are two things: poll frequency, and evaluation pool
<jpoiret>is c-u much longer than master? is it because it has to bootstrap guix's inputs first?
<civodul>poll frequency is OK and there’s POST requests too
<civodul>jpoiret: yes
<civodul>and recently some were just seemingly hanging
<civodul>not sure why
<civodul>hanging or taking a veeeery long time
<efraim>ok, I'm not upgrading swc until we are ready to use it for something, way too many subcrates
<apteryx>ACTION has been helped by 'guix locate' twice already
<apteryx>ACTION hopes it gains networked-fed databases at some point
<apteryx>do we have a way to declare a package as architecture agnostic? (data)
<apteryx>or that'd be handled by a cross builder that'd do the same as the builder?
<janneke>apteryx: an origin is architecture agnostic...
<apteryx>janneke: OK; but some packages, e.g. fonts, are built, but their result is data
<janneke>ah, right
<civodul`>apteryx: to guix-daemon though, it’s a “build process”, and it cannot know whether its output is system-dependent or not
<apteryx>right; it'd have to trust the declaration in package properties or something
<apteryx>there could be sanity check done e.g. looking if there are ELF objects in the output
<ulfvonbelow>I suppose that would require some sort of modification at the derivation level, such that there's a third type in addition to just normal and fixed-output, one that produces the same output paths regardless of the system of the derivation or any derivations in its input closure. But it sounds very unwieldy; what happens when a decision is made at the package level based on the system (for example, choosing different origins in
<ulfvonbelow>note that fixed-output derivations don't have to be just origins, downloader things, etc
<ulfvonbelow>the closest thing I could see (making it so that fonts and their dependents don't get rebuilt for each different system) would be making the font derivations fixed-output, and just recomputing the hash every time they're updated
<nmeum>I am currently trying to improve Guix dhcp networking service (currently it only supports isc-dhcp, which has reached end-of-life) would appreciate feedback from other dhcp-client-service-type users:
<peanuts>"[PATCH] Support dhcpcd in dhcp-client-service-type"
<apteryx>ulfvonbelow: that'd be some good starting point perhaps; it'd enable checking the result on any platform
<ulfvonbelow>although I don't believe we at present have a means of specifying an output hash for a package
<apteryx>we don't
<PotentialUser-61>Hi! I just upgraded Guix. Now I get this error when I try to start Emacs: "Symbol's value as variable is void: citar-indicator-create". Starting it with --debug-init does not show more information and a quick search only showed me this bug report:
<peanuts>"Installing citar with guix: "Symbol's value as variable is void: citar-indicator-create" ? Issue #814 ? emacs-citar/citar ? GitHub"
<apteryx>rekado: revert is now my favorite CSS value
<efraim>apteryx: we have some packages we mark as '#:target #f', a bunch in gnu/packages/firmware, but that only affects cross-building
<efraim>It'd be interesting to mark some JavaScript that way
<apteryx>rekado: how do I force refresh mumi.js in my local mumi instance?
<apteryx>it doesn't seem to pick up latest changes I make
<apteryx>(update: button looks good, but js wiring is not working yet)
<rekado>apteryx: you can change the URL of mumi.js to mumi.js?timestamp=12345
<rekado>we’re doing this for the CSS: (href "/css/mumi.css?20221231000000")
<apteryx>so everytime I want it reloaded I need to change the time stamp?
<rekado>since it’s a distinct URL your browser will need to fetch it anew, but it will remain cached until the URL changes.
<apteryx>can we have the guile http server use something like: Cache-Control: no-cache, must-revalidate
<apteryx>when MUMI_UNINSTALLED is 1
<rekado>you can also force your browser to reload the file
<rekado>in Firefox F12, then F1 to access the settings
<rekado>tick “Disable HTTP Cache (when toolbox is open)”
<rekado>we use that URL trick also when deploying mumi so that we can be sure that these files are reloaded by users
<apteryx>oh, the same exists in chromium (gear icon -> preferences -> Disable cache (while DevTools is open)
<rekado>(we could instead write an “asset” procedure that hashes the file contents and creates a URL with the hash appended to automate this)
<apteryx>thank you
<apteryx>knowing that toggle switch in browsers is good enough I think
<apteryx>perhaps we should write it down in HACKING or something
<apteryx>rekado: do you think a button 'title' can be changed in a CSS pseudo-class e.g. .my-button:hover::after { title: ...; } ? I tried and it didn't seem to work
<apteryx>For extra fancies, the hover text could show 'Copied' briefly after clicking on the button, ala github
<chsasank>Hey folks, I have a question: can I convert a docker-compose into a nice guix package?
<chsasank>With corresponding env files and what not.
<lispmacs[work]>hi, I'm trying to learn how to do package searches from the REPL. Something confusing me is that if I attempt to use find-packages-by-name or find-packages-by-description from the REPL, the command just cycles (apparently forever) at 40% CPU
<lispmacs[work]>Guile 3.0.9, with a Geiser REPL running inside Emacs 29.1
<lispmacs[work]>(find-packages-by-name "ascii"), e.g
<lispmacs[work]>do I need to initialize something first? (search cache?)
<rekado>lispmacs[work]: works for me
<rekado>I run “guix repl” and then ,use (gnu packages)
<rekado>then: ,t (find-packages-by-name "emacs-minimal")
<rekado>$2 = (#<package emacs-minimal@29.1 gnu/packages/emacs.scm:101 7effae1246e0>)
<rekado> ;; 0.002040s real time, 0.002036s run time. 0.000000s spent in GC.
<rekado>it’s almost instantaneous
<jpoiret>lispmacs[work]: are you using a guix checkout?
<jpoiret>there I don't think there is a package cache, so it might take some time
<rekado>chsasank: I don’t think a Guix package is meant to work like docker-compose
<lispmacs[work]>jpoiret: when I load the modules, it appears to load the code from one of my guix checkouts I cloned a while ago
<lispmacs[work]>rather than the from the current-system profile
<lispmacs[work]>I didn't realize it was doing that, not sure if that would be a problem or not
<lispmacs[work]>I'm not sure how to use the package cache, or how that works exactly
<lispmacs[work]>I'll take a look at my geiser paths, anyway
<chsasank>rekado: why not? there seems to be guix services too.
<mekeor>lispmacs[work]: do you use "guix repl" (or start guile manually)?
<lispmacs[work]>I just run M-x geiser inside Emacs, and then ,m (gnu packages) or whatever
<lispmacs[work]>I mean, ,use (gnu packages) or whatever
<lispmacs[work]>Do I need to run a special REPL command first? I didn't use "guix repl" from the command line as I was trying to avoid the command line
<zyd>You can do what I do: (setq geiser-guile-binary "guix-repl"). Where `guix-repl' is the name of a shell script in your path (like ~/bin) that simply calls the command `guix repl'.
<lispmacs[work]>zyd: okay, thanks, though that seems like a rather cludgy way to go about it, to be honest. I see that guix repl has a listen option, so I could connect geiser to it that way
<lispmacs[work]>though it seems like I should be able to launch that without the shell. Maybe I can take a look at guix-repl source
<rekado>the most recent master evaluations don’t look good:
<rekado>“unsupported openssl target kernel”
<rekado>I guess this is fixed by 3aa60e4096e5a9e880c9545cd28ec4aab610753f?