IRC channel logs
2024-01-23.log
back to list of logs
<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>rekado: phew, finally nailed the CSS right <rekado>apteryx: pico is a glorified reset CSS. <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 <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 <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. <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 :-) <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) <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) <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?. <apteryx>sneek: you confuse mirai with mekeor <janneke>wow, the new pretty-printed builders are nice <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 :) <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>i guess we'll just have to write more efficient build recipes <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? <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 <jpoiret>no one builds packages themselves tho, right? <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 <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 ci.guix.gnu.org is a little behind <rekado>it only just got the change to commit 9b65b60. <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? <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>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? <rekado>“guix weather” says there are no substitutes for gtk+ <efraim>we had an emacs kerfuffle where emacs-minimal got bumped and then reverted <rekado>commit 0afe456973e8d5d51ea23c41579b94bde99d08d8, but I’m way past that commit <efraim>gah, it was me. source-highlight is load bearing <rekado>probably 367bc2d198f57bc34522441820f761b61fed0ce0 <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>and recently some were just seemingly hanging <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 <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: https://issues.guix.gnu.org/68675 <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>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 <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>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 <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. <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]>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 <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]>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>“unsupported openssl target kernel” <rekado>I guess this is fixed by 3aa60e4096e5a9e880c9545cd28ec4aab610753f?