IRC channel logs
2024-11-06.log
back to list of logs
<yelninei>vagrantc: d076ae1c7a3ab34c1d7103b70887eedb2e38a0f5 is the commit that caused many rebuilds. The indent update causes gnulib and thus patch to rebuild. This causes a rebuild of linux-libre source and then all kernels <yelninei>problem is that this is invisible to guix-refresh beacuse the patch and make-linux-libre-source derivations import #+patch resp #+gnulib directly <vagrantc>anyone have recommendations on how to figure out which texlive packages are needed to build a given document? short of building it iteratively and checking for failures? <vagrantc>also, what sort of packages do i need to install a font? i get only nullfont ... trying to build in "guix shell --container --pure" so i guess no "system" fonts are available <jakef>vagrantc: for the 2nd one, try including fontconfig package <vagrantc>ACTION has found texlive-collection-* and texlive-scheme-* <vagrantc>installing fontconfig and a font did not result in any fonts available <vagrantc>let's see how installing a few collections does ... <vagrantc>this is where guix's oh, download 10 MB ... done ... oh wait, i missed something, downloading 8 MB ... done. oh wait, Downloading 29MB ... cycle gets a little tiresome :/ <vagrantc>this is with a single guix shell command ... <vagrantc>i guess guix can't figure out how much it needs to download without downloading some of them first? computed derivations or something? that has always confused me a bit <pkill9>yeah that's annoying, i think it's due to grafting <vagrantc>FWIW, this eventually worked: guix shell --pure --container coreutils-minimal emacs-no-x make texlive-collection-fontsrecommended texlive-collection-plaingeneric texlive-collection-latex texlive-collection-latexextra <vagrantc>maybe could trim it down further, but i got pretty weary of the whack-a-mole game <hako>podiki: Thanks for mesa-updates! I'll prepare the series today. <sneek>hako, podiki says: with mesa-updates merged should be easy (i think) to upstream hyprland, thanks for maintaining that! <podiki>awesome! thank _you_ for the packages/channel :) <getstate>I'm having email deliverability issues with my provider, is it fine if they send a test mail to guix-patches@debbugs.gnu.org? <janneke>getstate: guile-patches receives ~50 mails per day, how would another mail help test if it gets delivered to you? <mange>It sounds like it might be the provider themselves, doing so to see something like the SMTP response. <getstate>mange: yes, that is what's going on. The issue is about the "sending" aspect. <mange>I can't speak for anything official, but I imagine sending an email to guix-patches will be fine. I think mail from new addresses is moderated, so presumably it wouldn't make it to the actual list. <Ironsmith>heya guix! when using gnome-disks, i'm able to create partitions but when i try to format or label a partition it keeps giving me: 'executable mkfs.ext4 not found' even though i can call it without issues from the terminal https://ibb.co/GMxtFbH <sepeth>Ironsmith: maybe mkfs.ext4 is in your profile but things aren't properly source'd for the graphical environment. <sepeth>maybe try running grome-disks from the same terminal session. <Ironsmith>thanks sepeth, gave that a shot but it didn't work <Ironsmith>i also tried explicitly installing `gnome-disks` and `mkfs.ext4` via `guix install gnome-disk-utility` and `guix install e2fsprogs` <decfed>Kolev: not on Fedi. Store could also be /var/gnu/store, I suppose. /var is mutable, so anywhere there is fine <dariqq>hi, is diffoscope failing to build for anyone else (test failures in u-boot-tools dependency)? <dariqq>slightly annoying is that u-boot-tools is also blocking genimage <sleepydog>this is interesting. several of my log files in /var/log have 512 NUL bytes in the middle of them. anyone else see that? <sleepydog>i noticed because grep complained that /var/log/messages was a binary file <dariqq>even more annoying: custom test phase in u-boot-tools ignore tests? variable ... <futurile>it would be really nice if master had a gate on it master so that it warned you about regressions <dariqq>it would be really nice if packages in guix actually follow the standards in guix itself. Custom check phases that are unskippable are so annoying because it breaks the --without-tests transformation in case tests fail (i.e. other architecture, new dependency , ...) or are time-intensive <efraim>`guix lint -c tests-true` only lists a handful now <dariqq>efraim: i am talking about custom check phases that ignore the tests? varaible. Dont think this is the same <efraim>ah, yeah, they're not supposed to do that <dariqq>a lint rule for this would be nice, but idk how I would check for this <Rutherther>dariqq report it or send patch. Stuff like that happens, its a mistake, not intention... <efraim>cbaines: it looks like the TLS certificate for patches.guix-patches.cbaines.net expired <dariqq>Rutherther: apologies for a being a bit frustrated. I think I'll see if i can devise a lint rule to find all packages currently in guix and hopefully prevent it in the future <jakef>efraim: with your rust packaging hat on, do you know of any issues with packaging ruff, the python linter? <efraim>jakef: I haven't taken a look at it yet. it would be nicer if it were on crates.io, then we could just import it easily, and checking the Cargo.toml on github it looks like there's a lot of dependencies <jakef>ok yeah, hopefully they get around to putting it on crates. thanks for taking a look :) <efraim>it might not be as bad as it looks, a bunch of their crates in the crates/ directory say to just use the dependency already in the workspace, so perhaps it is just the one big list in the base directory and not also another 20 Cargo.toml files to read through <dariqq>oh it seems there is already a lint-rule 'guix lint -c optional-tests' but it falsely succeeds for u-boot tools <dariqq>ah , the rule only checks for (replace 'check _ ) and not other variants of a custom check <efraim>dariqq: I can take a look at u-boot-tools and make sure I don't break anything wile making the tests respect the #:tests flag <dariqq>efraim: well i dont think you can make it worse anyway because tests are currently failing (on x86-64) <dariqq>no, that started my little rant earlier (and this is blocking diffoscope and genimage for me) <futurile>cbaines: would it actually be possible to notify if a merge was going to break builds in master that were currently working, in a <handwave> way? <dariqq>efraim: thank you , i just sent #74225 to make the linter see custom checks that e.g. add the check after install. There is still a problem that it doesnt find check phases not named 'check but this is a problem for another time <pjals>Hey, aren't native-search-paths of dependencies supposed to be set when using guix shell -D? <Rutherther>pjals they should. As long as the path they use exists in the profile <divya>Hello, can someone help with understanding how to work with build phases and g-exps when packaging something? <lispmacs[work]>hi, I came up with a patch for an open bug, which I have in a git-generated patch file that I'm ready to e-mail. Do I just respond to the bug thread, with the patch attached, or are there any special control messages or subject line changes I should make? And is there a patch e-mail address I should CC? <divya>The package has a meson build that is hardcoded into writing into a file outside of the store (in /etc/xdg), and that needs to be changed. I was suggested in the mailing list that I should do something with #option and build phases, some hints or help would be helpful. <ieure>lispmacs[work], Should cc guix-patches@gnu.org <ieure>lispmacs[work], `git format-patch' should do that for you. <lispmacs[work]>ieure: I used format-patch, but I don't see how that affects the subject line of my e-mail (...?) <Rutherther>ieure but if they cc patches there will be two tracking numbers <ieure>lispmacs[work], Yes, the output of `git format-patch' is an email. <ieure>divya, You want: (arguments (list #:phases #~(modify-phases %standard-phases (add-after 'unpack 'patch-path (lambda _ (substitute* ...)))))) <lispmacs[work]>ieure: do I do anything special as far as how I attach or send the e-mail in guix? <ieure>lispmacs[work], I don't use Gnus, so I have no idea. I send patches with `git send-email'. <divya>ieure: Thank you. But can you elaborate on how exactly to use substitutes? I don't understand, is it a derivation .drv or something else? <ieure>divya, substitute* is a Guile procedure for programmatically editing files and has nothing to do with Guix package substitutes. <ieure>It's documented in the Guix manual. <pjals>substitute* is part of Guix's build utilities, not part of Guile's guile-user environment. <pjals>It's in the (guix build utils) module, I think. <divya>It can be used in any build-system? <pjals>Yea, as long as you import it. <ieure>Sent another round of patches to #74070 if anyone's inclined to take a look. <ieure>(It now updates to 132.0-1, since that came out while the previous patch was languishing.) <divya>ieure: What are we doing with add-after 'unpack 'patch-path? <ieure>divya, Changing the hardcoded "/etc/xdg" to something else. <divya>'patch-path is for that path? I see. <ieure>divya, 'patch-path is an arbitrary symbol describing what the phase does and its precise value doesn't matter. <divya>In the librewolf source you shared, the string-append procedure takes #$output, what is that? <rekado>divya: #$output is the generated target location in the store. <ieure>divya, Yes, it's where the build process puts its results; the contents of output are the package contents. <divya>I see, can you elaborate on how exactly does this work? Like, it is a procedure? <rekado>everything starting with #$ is pasted as a value into the expression introduced with #~ <ieure>#$ is the "ungexp" macro. If you've used Lisp, it's the equivalent of unquoting within a quasiquote form. <rekado>divya: it's documented in the manual. Look for G-expression. <divya>ieure: In 320 of the librewolf.scm the substitute* is applied on a file, what's the location of that file? Since the .scm is not going to be in the directory of the source, which file path do we provide? <pjals>Is `inputs` supposed to be use for build inputs like (static) libraries? The documentation says that native-inputs will be built for the build machine so the libraries should be built for the target (inputs), right? <ieure>divya, The build runs with its $PWD set to the directory the source was unpacked. <Rutherther>pjals: exactly, libraries go into inputs. Only stuff that's ran on build machine during build goes to native-inputs <pjals>What about toolchains though? (or in my case, the lack of them), do they go in the bag's build-inputs? <Rutherther>pjals: not usually. Depends on what you do with them. If you use them during build, they go to native-inputs <PotentialUser-85>I used Guix after I while and when ran guix pull it gave "guix package: error: executing SQLite query: database disk image is malformed <pjals>Ooh, that's not good. Try fsck'ing and in the worst case, delete /var/guix/db/db.sqlite and re-init the system. It won't delete your profiles, but you'll need to init your profiles again to download everything to the store. <pjals>For some reason Guix's database is corrupted, is your hard drive dying? (never run a database on an SD card!) <pjals>That is interesting, do SMART tests point anything out of the ordinary? <Rutherther>if you were to remove the database you should also remove store and the profiles. Since if store paths exist, but aren't in db, there can be problems. And profiles since the store paths don't exist anymore <Rutherther>but you can also just try running repair on the sqlite database, it might work. Or not, you never know <pjals>That *would* be `smartctl -H /dev/sdxN`, but you probably do not have that downloaded in any profiles. <pjals>Oh right, I forgot about repair :P Try `guix gc --verify=repair` <Rutherther>pjals: that's not what I meant, that won't work here <Rutherther>searching for it since I forgot the command. Sqlite has a repair command <pjals>I havent tried it, but wouldnt guix gc --vacuum-database do something like that? <PotentialUser-85>it said Throw to key `sqlite-error' with args `(sqlite-exec 11 "database disk image is malformed")'. <pjals>Could you copy the database to another machine (don't turn off your current one) and try loading and dumping the database from there? <ieure>PotentialUser-85, sqlite isn't in your profile, but maybe it's in the store? Does `ls -d /gnu/store/*sqlite*' show anything promising? <Rutherther>PotentialUser-85: like the binary? Are you sure, though? As far as I know the library is in the same package and output as binary. So you should have it, otherwise guix wouldn't be able to use it <pjals>How does Guix use sqlite? Guile bindings? <Rutherther>no, the guix daemon uses it to store info about store paths <ieure>A bajillion things use SQLite. <PotentialUser-85>ieure I did show /gnu/store/xmzx5mzv4863yw9kmr2ykndgp37p8if0-sqlite-3.36.0/ <ieure>PotentialUser-85, Promising! What's in the bin/ directory of that? <pjals>(we could always just use the Guile bindings (in the base packages!!) if there are no binaries :P) <PotentialUser-85>I ran the command but it said cat: /dev/fd/63: No such file or directory <PotentialUser-85>I remember something now, when I was using ventoy I open some iso but Guix opened instead of it for some reason but the guix system had my previous config and was also running someware that I had removed later and the browser was also running a video it was how I had left and rebooted after updating my config I while ago. <pjals>Maybe the Guix system is a bit too reproducible then :P <PotentialUser-85>should I reboot and run fsck from another distro installed on another drive <pjals>Wait, but you're running from Ventoy right now right? <PotentialUser-85>now I am currently using the normal guix but I have ventoy with me in my pendrive <pjals>Is there a way to specify a specific target (not system!!) with guix shell? Specifically i686-elf. <Rutherther>pjals: so what do you mean by target, but not system? <pjals>target as in a target architecture, for building a kernel (i686-elf), system as in a kernel, for building userspace applications (i686-linux) <pjals>Right now Guix is building i686-unknown-linux-gnu-gcc, which is suspiciously not i686-elf-gcc <pjals>guix shell --list-systems does not provide i686-elf as an option, so I assume I need to set the target in some way <Rutherther>pjals: all targets are under --list-targets, but currently i686-elf is not supported I suppose <ieure>divya, Hmmm, error implies that output is unbound, which I don't think it should be. I'm not sure why that's happening. <pjals>You are not allowed to specify a target. Only a system with --system (and options are under --list-systems) <ieure>divya, You can try changing the lambda to (lambda* (#:key outputs #:allow-other-keys)) -- then instead of #$output, do (assoc-ref outputs "out"). <Rutherther>pjals: what do you mean not allowed to? --system is for native build using the given system, via qemu emulation. --target is for cross compilation <pjals>--target is not an option for guix shell.. <Rutherther>pjals: of course not, since that would mean run as that architecture. I wouldn't expect to be able to compile bash and such for i686 anyway <pjals>I'm making a kernel, of course I would expect that. <Rutherther>s/since that would mean run as that architecure/ since that would mean run as current architecture the programs for target/ <Rutherther>pjals: but then you should make a new target for that kernel if you want stuff built for it. Only the kernel will build for i686-elf, and rest for that kernel <pjals>I'm not ready to make a toolchain for my kernel. I just want Guix to get me a compiler for i686-elf with no specific system branding. <divya>ieure: the substitute* procedure should come inside the lambda* <Rutherther>pjals: then it sounds like you want to get the gcc-cross for "i686-elf" or something like that <ieure>divya, (lambda* (#:key outputs #:allow-other-keys) (substitute* ...)) <Rutherther>not specifying any flags, but using the cross gcc function <pjals>Rutherther: So I assume I use a custom build system for this? <Rutherther>"(cross-gcc "i686-gnu")", where cross-gcc function is from "(gnu packages cross-base)" <pjals>Wait but no, that doesn't make any sense. gnu-build-system is already using cross-gcc? <pjals>I just want to set the target option passed into the lower of gnu-build-system.. <Rutherther>pjals: you said you want the compiler, so guix shell --expression "((@ (gnu packages cross-base) cross-gcc) "i686-gnu")" will get you a cross compiler in a shell <divya>ieure: Looks like the same thing in the error. <pjals>Maybe I phrased that unclearly. I want Guix to get me a compiler, specifically i686-elf-gcc, for my build system to use to compile my kernel. <Rutherther>pjals: okay, then what is the shell supposed to be for? <pjals>For getting development dependencies for my project, I think. <Ironsmith>is it possible to `(define)` a `(file-system)` like so? `(define my-usb (file-system (mount-point "/mnt/my-usb") ...))` then use it within (file-systems) like `(file-systems (cons* my-usb (file-system ...) ...)` ? <Ironsmith>i get the error `config.scm:57:4: error: (define my-usb (file-system (mount-point "/mnt/my-usb") (device "/dev/sdc2") (type "ext4"))): invalid field specifier` <Rutherther>pjals: then I am lost. If you want to make a build system to run in guix, why would you need development dependencies in a shell? they are provided inside of guix with inputs and such <ieure>divya, Hmmm, that's odd. I'm not sure what's wrong. <pjals>Rutherther: Sorry, I am bad at explaining things. I am making a kernel and would like to build and develop it with Guix. I am doing this by making a package for it with the nessecary phases and inputs for building it using the gnu-build-system. The problem here is that guix shell -D does not allow me to pass a system for retrieving build-inputs, so it is giving me the i686-unknown-gnu-gcc instead of the <Rutherther>pjals: Aha! So then that seems like a limitation of guix shell -D <pjals>By the way, how does Guix expect programs to find the compiler other than brute force without an environment variable? <divya>ieure: Even if I remove #$output, the error persists. And the 37:15 line seems to be starting at #~(modify-phases %standard-phases) <divya>do i need to import some module for using gexps? <ieure>divya, You (guix gexp) is it, you're already using it. <divya>yep that was it, fixed it. Hopefully the build now works, thanks ieure. Really appreciate. <Rutherther>pjals: while guix shell -D doesn't support this, package->development-manifest, which it uses under the hood, does. So you can just make a manifest out of (package->development-manifest package #:target "...the target...") <divya>No worries ieure I hadn't imported (guix gexp) lol <pjals>Rutherther: Oh, that's great. Thank you! <Rutherther>pjals: I don't think it is expecting that. It is expected you provide the environment as necessary so that the package is buildable <pjals>Doesn't gnu-build-system already set environment variables for some scenarios? Why should it stop there? <Ironsmith23>should i used `(let ((my-usb (file-system ...))))` instead of `define`? i'm getting a `extraneous field initializers (let)` error with that though <pjals>Ironsmith23: You're using let wrong in that case, try using let in whatever field's value? <pjals>(using let vs define is like local variables vs global variables) <pjals>Just never ever use define in the middle of a function. It's not lispy. <fnat>Do you know if anything has recently changed with Guix's Tor Browser? It used to work up to some time ago, I tried it again today but it asks to restart the Tor server. Do I need to separately set up Tor as a service now? <fnat>I should add: it asks to restart the Tor server and then if I click on Restart, nothing happens. <ieure>Ironsmith, You should be able to define that stuff and reference it, error indicates that something is wrong with the (file-system) form itself. <pjals>They were probably doing (whatever-record (field value) (let ((a b)) (another-field a))) instead of (whatever-record (field value) (another-field (let ...))) <pjals>This is probably a stupid question, but is there any way to set environment variables for building for -D such as ARCH=target? <pjals>I'm stuck making my project more and more Guixy :P <fnat>Follow-up on my Tor Browser issue: nothing to see here, it was an issue between Guix and the chair. <pjals>By the way, how should dependencies used for testing (like qemu for a kernel) be handled? <noe>When reviewing is it better to point out typos or send an updated patch (or both) ? <pjals>Point them out and suggest changes in the same email. <weary-traveler>for those who wish there were a more emacs-centric way to send patches for guix (and other projects that use patch emails), see #74231 (and associated project) <Ironsmith>thanks ieure, i'll double check that it works in-place <stochastic>Is there anything in the works to add TRIM/discards to an encrypted drive in Guix? <stochastic>I saw a patch about it not long ago, it's pretty good for SSD health <ieure>stochastic, That's not recommended with any FDE setup. <stochastic>> stochastic, That's not recommended with any FDE setup. <stochastic>For security reason, or does it have no benefits at all? <ieure>stochastic, For security reasons, it can leak information about the use of the encrypted drive. <ieure>stochastic, You have to trade off some SSD life for improved security. <stochastic>> stochastic, For security reasons, it can leak information about the use of the encrypted drive. <stochastic>What if my threat model doesn't need plausible deniabilility? <ieure>stochastic, Go hog then. Or use the hardware OPAL SED stuff. Or rawdog and use nothing. <ieure>But the default across multiple Linuxen is to disable TRIM on FDE volumes, because security ought to be the default. <ieure>For whatever it's worth, I have FDE SSDs that have been running for ~8 years and I haven't noticed any degradation. <stochastic>> But the default across multiple Linuxen is to disable TRIM on FDE volumes, because security ought to be the default. <stochastic>I agree, but there's already a special struct for luks options. It shouldn't be the default, but I think it would be interesting to have it available. <pkill9>is there a distro basded on guix? I thought I re4member reading about it <attila_lendvai>stochastic, IIRC nckhexen (nckx) has some trim/discard changes that are not upstreamed yet <divya`>Okay, something is funky with my guix sound setup. <ieure>divya`, It's playing Parliament's classic "P. Funk (Wants to Get Funked Up)" off their seminal 1976 Mothership Connection album? <ieure>Oh, it's the bad kind of funky then. <divya`>yeah bad indeed, has been messing up my meetings <divya`>but basically my pipewire/jack/pulseaudio thing is not working as its supposed to <divya`>I do pw-jack to run a jack client it doesn't work. Sometimes pipewire just randomly decides to not take input from my usb mic or not provide output to speakers. <divya`>I don't even have any special setup yet, as the config shows. <divya`>yes, to add the pipewire home service in home configuration <divya`>I was recommended this in the mailing-list. <attila_lendvai>stochastic, the easiest way would be to have a fresh enough grub, then use luks2 headers, and set the flag there. otherwise guix must be patched to call cryptsetup with the right command line. <divya`>I don't know what's happening, suddenly speakers have no music then I do herd restart pipewire and it starts playing. <KE0VVT>I'm trying to get Guix on Silverblue. I cannot find the systemd service file in /var/guix/. <Kolev>futurile: Thanks. Emailed him. <divya`>During building a meson-build-system package, I encounter the error No file or directory found: gtk-update-icon-cache. I searched and found that you need to install gtk+:bin in guix profile, did that but nothing changes. Any ideas? <ieure>divya`, When you say "you need to install gtk+:bin in guix profile," how exactly are you doing that? <ieure>(I think I know what's wrong, just don't want to assume, so, checking a thing or two first.) <divya`>I have tried doing it through guix install and guix shell <ieure>That is incorrect. Packages are built in isolation to ensure reproducability, and nothing in your Guix profile affects what the package sees. <ieure>What you need to do is add the gtk+ package's "bin" output to your package inputs. <ieure>Any package your build depends on must be in the inputs. <noe>something like (inputs (list `(,gtk+ "bin))) iirc <Sharlatan>I need som Gule hack to produce a list: where build-system = A and sort it by number of dependent <divya`>I got my first guix package to build and install :) <divya`>Only to not run /sigh/. Today has been a difficult day. <divya`>I think its a path issue again, the build worked fine and the app installed. But its a python app and its having the classic "No module named [app]" <lispmacs[work]>in some dusty old code a found a reference to something called "guix potluck" (...?) <olafes>hey, I was thinking of setting up guix system with zfs root but sadly it appears impossible. So I've got another brilliant idea: have zfs root but use guix as a main package manager. Are there any obvious problems with this approach?