IRC channel logs


back to list of logs

<mirai>you don't need to do that
<mirai>use the bibtex format
<Kabouik>A flatpak program is complanining about and not found, yet openssl is installed. Could it be that flatpaks can't access those libs on Guix?
<gabber`>Kabouik: you might have to explicitly tell your program where to find these
<rekado>it doesn’t start because a log file is owned by root
<Lumine>Kabouik: you can use Flatseal for access control for individual flats btw
<rekado>I chowned the files and started the bot again
<gabber`>\o/ goggles-bot is back!
<rekado>maybe someone messed around with the logs and forgot to change ownership
<rekado>no idea
<Lumine>Yay for goggles-bot !
<gabber`>rekado: thanks for reassuring them!
<gabber`>any idea where i can find goggle's sources?
<rekado>goggles and goggles-bot are both there
<rekado>and the viewer:
<mirai>is it possible to retrieve the "latest" patch (or series of patches) for a given issue?
<apteryx>in Emacs with Debbugs: M-x cd -> place your directory to your guix checkout; then put your cursor on the first mail, then C-u N | git am -3 RET, where N is the number of messages/patches you want to apply
<mirai>I'm looking for a more programmatic way of doing it
<mirai>for a "merge-conflict" checker
<apteryx>or rekado authored some email-related Guile bindings that you could use to accomplish something in Guile
<mirai>I was thinking on something similar to qa.guix
<cbaines>The qa-frontpage at uses the branches here
<mirai>but it tries to apply patches for open issues everytime the tracked branch changes
<cbaines>those branches should reflect the latest set of patches applied to some recent revision of Guix
<mirai>is QA able to detect "branch rot" ? (that is, patches that no longer apply)
<cbaines>mirai, sort of, but it doesn't do much when an error is hit when applying patches
<mirai>it'd be nice to get some sort of notification for open issues that the patches no longer apply
<mirai>as a heads up for the author to rebase
<unmatched-paren>ACTION sends monad blog post v2
<a12l>When you're doing rust dev on guix, should you use cargo files or only guix files (that use cargo in the background?
<a12l>I.e. (guix build-system cargo)
<lfam>Howdy everyone at the Guix Days. I'm curious if there is a projector / beamer, and if it does HDMI?
<Kabouik> Thanks gabber`, Lumine. I didn't know about Flatseal, I just used it to give access to that other app to my system libraries, but that doesn't seem to be enough. I'll see if any other option might be required.
<a12l>Also got this error when I run guix pull:
<a12l>How are I'm supposed to get "the full output"? Rerun the command, or is the output saved in some log somehwere?
<apteryx>it's probably a network-related issue
<apteryx>or load-related, on your end or on the server. you could try --fallback if a second 'guix pull' fails the same
<a12l>apteryx: thanks! after some reasearch it seems that there's no free space left on my SSD
<apteryx>that'd make a nice bug report, the crash, and the actual problem
<apteryx>so that we can improve the error reporting
<a12l>I can send in that, if you would like to have it :)
<jonsger>lfam: yes, and it does HDMI
<lfam>Thanks jonsger
<lfam>I have a brief presentation / discussion I'd like to give tomorrow
<Kabouik>Do you have any experience using Flatseal to give access to flatpaks to things like openssl Lumine? The options I tried did not change anything. Maybe Flatseal is not of much help with the Guix file hierarchy?
<apteryx>a12l: yes, please!
<a12l>Does the bug tracker expect a special formatting of the mail, or is it just to mail it in?
<gabber`>no special format needed or expected :)
<Fd9a>Hi. I built the debian package of guix for riscv with guix pack --system=riscv64-linux -f deb, after installing in /gnu/store some files have a date other than 1 jan 1970, should I change it manually or should I just leave it as it is?
<gabber`>are these dates reproducible or do they differ with each build?
<Fd9a>It took me a week to build this, so I can hardly check. The date falls in the middle of the week with almost the same time.
<gabber`>why do you want to have the dates be UTC 0? i thought you created a package that you built with the command above and were getting strange artifacts in your store
<a12l>apteryx: Done
<apteryx>thank you!
<Fd9a>gabber`: I'm not sure I want this. Checked it on the main car, it didn't happen there. So far everything seems to be working, so nothing critical.
<gabber`>i think the only reason the timestamp is set to UTC 0 in the store is to guarantee reproducibility. i don't think it's necessary to change anythingif you don't care about that and your software works fine
<rekado>mirai: /issues/<id>/patch-set/<num>
<Guest46>Is ZFS available on Guix or will be?
<bjc>it is, but support is limited
<bjc>you won't be able to auto-import pools as part of the normal file system mount operations, for instance. so things like having your home directory on a pool won't work well
<Guest46>k thanks
<old>Is there a time limit we want for tests of package?
<old>I have a package with #:tests? #f for now. If I were to enable it, tests can take up to an hour
<old>Is that something acceptable?
<Guest46>I would think it is still fine, since it is run only once on the substitute server and it ensures quality.
<futurile>Q: I'm looking at rust-env-logger in Guix, the actual name on is env_logger: in Guix it's a hyphen, in rust it's an underscore. Is it intentional that we convert underscores to hyphens?
<apteryx>I think I've found my issue with the first guix pack test suddenly using lots of dependencies after my rework: I've introduced some computed-file objects, that don't seem to use the %guile-for-build fluid
<apteryx>the test suite sets that so that the guile-bootstrap variant is used and dependencies kept to a minimum
<mirai>old: imo it should be fine, better to be sure that the package works
<bjc>futurile: yes, it's intentional. in addition, there's no difference between ‘-’ and ‘_’ when it comes to crate names; they map to the same object
<futurile>bjc: ah, OK, interesting - didn't know that about Crates. Not actually that familiar with them/Rust - thanks
<florhizome[m]>I am still getting a Message about a Not supported manifest Format when trying to Install, remove, Upgrade etc
<florhizome[m]><florhizome[m]> "I am still getting a Message..." <- Oh. For some reason i had 2 generations with empty manifests
<nckx>Fd9a: Which files, for example?
<seninha>ok, i give up on this ugly service. i'm not that guix/guile literate to change a service or write one from scratc. Since this machine is just for development and testing purposes, im gonna just launch the daemon manually.
<apteryx>old: not everyone uses substitutes, and when testing affected packages, 1 h seems a long time to wait to know the result
<nckx>rekado: I did, when copying residue from 2023-01-31.log to 2023-02-01.log. Bash history says I typed ‘cp’ where I meant ‘cp -a’.
<apteryx>it'd be preferable if a subset of tests could be run in a reasonable time and give a good idea of whether the software works as advertised; some python packages tag their slow test with a marker, like 'slow', and then we can invoke 'pytest -m not slow' to skip them
<apteryx>yay! (guile (%guile-for-build)) in computed-file solved my last 'guix pack' failure
<Fd9a>nckx: directories of packages and dirs inside of them for example /gnu/store/hz4hb8sva8ihm8gynw80kb85hqd7drzc-libunistring-0.9.10/
<nckx>Could you share the full command? I'd like to try.
<mirai>seninha: did you try adding the field
<mirai>to the config
<seninha>mirai: you mean, to gnu/services/vpn.scm?
<apteryx>is it possible to ungexp a procedure that returns a gexp inside a gexp expression? E.g, #~(begin (display #+(some-proc some-value)) ...)
<apteryx>currently I'm getting: Wrong type to apply: #<gexp (begin (setenv "GUIX_LOCPATH" [...]
<mirai>seninha: clone guix source and build from source
<mirai>apteryx: there's approximate sexp
<apteryx>wait, I think perhaps it works; at least it did for some tests
<mirai>I've had a similar problem when I was using generic-serialize-alist
<seninha>mirai: thanks, but i'll just start the daemon manually, from a script. It's just for developing a custom cryptographic engine and testing it, i do not want to keep the service active for much time all
<seninha>i'll probably hit a point where i'll need to pass more flags and do finer configuration, which will require me to patch the module again
<mirai>This looks redundant: #~(string-append #$@(generic-serialize-alist list mpd-serialize-field value)))
<mirai>You'd think (generic-serialize-alist string-append <lambda> value) would perhaps be better
<mirai>but if lambda returns gexps, string-append won't work with them
<old>apteryx: okay thanks
<Fd9a>nckx: guix time-machine -C channels.scm --disable-authentication -- pack --system=riscv64-linux -f deb guix I used my channel where I disabled tests for some packages because the cross-compilation fails. which is checkout from ae071e21f3a42c0c30b5c83f90a9ca022ebcac4d master
<apteryx>old: yw (and hi!)
<aaaa_bbbb>hello, anyone here use emacs for guix development
<aaaa_bbbb>would you mind sharing your config, i would like to contribute to guix too at some point
<bjc>try starting here:
<aaaa_bbbb>bjc: tnx
<mirai>you don't need to pimp your emacs much to get started hacking guix
<mirai>it makes things easier but it's not strictly required
<mirai>(running near vanilla emacs since I haven't wrapped my head around this way-of-editing yet)
<apteryx>shouldn't it be possible to (mkdir-p "/var/lib/rpm") inside a gexp build?
<apteryx>worked around it by creating an rpm variant with its localstatedir set to /tmp
<jackhill>apteryx: wouldn't it need to be (string-append #$output "/var/lib/rpm")?
<jackhill>/tmp may be better for what you're doing anyway though
<apteryx>the localstatedir of the rpm package is baked at build time
<nate1>Trying out guixsd, how does one run scheme code in a repl?
<mekeor[m]>nate1: did you run "guix repl"?
<mekeor[m]>which/what code do you want to run?
<nate1>oh yeah, guix repl is what I was looking for, there was some scheme code to add stuff to system config that I dont have handy right now
<mekeor[m]>you can also help yourself by searching the manual for "repl" or, better, using its index:
<nate1>That is very handy, is the manual located locally as well?
<vagrantc>efraim: i noticed you changed diffoscope to build with cdrkit-libre ... it should probably also be changed in upstream diffoscope if it is indeed fully compatible ... although guix has both cdrtools and cdrkit-libre ... either could technically work?
<patched[m]><nate1> "That is very handy, is the..." <- The manual is available as infopages, `info guix`.
<tschilptschilp23>Hi guix! I do not have to seem the 'locale' command on my system, any hints which package am I missing?
<tschilptschilp23>s/have to seem/seem to have/
<tschilptschilp23>It's set to 'en_US.utf8' in the operating-system section of my system-configuration, but I do not know how to 'retrieve' the value.
<tschilptschilp23>ACTION is happily using guix the third year without ever having installed glibc
<mekeor[m]>tschilptschilp23: how about $LANG?