<muradm>just wander how to move it forward <lfam>muradm: I'll try it out later today! <vagrantc>acutally had to build linux-libre on aarch64 for the first time since i started using substitutes from bordeaux *vagrantc hopes it catches up and can run guix challenge on it <vldn>i got permission denied on a build of the newest version from sway.. maybe someone can help me :) <vldn>PermissionError: [Errno 13] Permission denied: '/gnu/store/c1j7wn0s3a279frix2sfmpm2n0ncjyj4-bash-completion-2.8/share/bash-completion/completions/sway' <vldn>python doesn't have enough permission to create the bash completion things <Noisytoot>Do you get substitutes from bordeaux by default? <lfam>vldn: The only directory that the build process can write to in the store is the directory created by the build. This /gnu/store/...-bash-completion directory is already "done", and cannot be changed <lfam>You'll need to adjust the build scripts of your package to put the completions in its own output directory <vldn>mh these parts aren't in sway 1.5.1 <vagrantc>Noisytoot: 2e30e84b64b4cc8ca7f40fbe65d01b2477b75311 services: guix: Authorize 'bordeaux.guix.gnu.org.pub' by default. <lfam>vldn: Take a look at the dstask package in gnu/packages/task-management.scm' <lfam>And if you grep for 'completion' in the packages, it looks like there are lots of packages that have to deal with installing the completions. I guess it's a common upstream blind spot <lfam>The example in libabigail is simpler than the one in dstask, vldn <lfam>Can you clarify what you mean MeowcatWoofWoofF? <lfam>Guix does support i386 (we call it i686) <MeowcatWoofWoofF>I notice my repositories have software labeled for i386 and others for i686 <lfam>I think I messed up the weather reports <vldn>lfam possible to modify the bash-completion in the ninja install phase? via the modify-phases? <vldn>my problem is within the meson-build-system (trying to update sway to 1.6.1 ) <lfam>Almost anyting is possible, since you have all of the Guile Scheme programming language available <lfam>Maye the meson scripts take an argument to change the location of these files <lfam>Or maybe you'll have to patch the meson scripts <lfam>Also, almost every other distro will have the same issue. So you could try googling your error message to see if anyone else reported it. Or check other distros package recipes if they have packaged 1.6.1 <lfam>Alright, so my weather reports were totally bogus <lfam>I don't think we've really attempted a full core-updates build yet <lfam>This cycle is harder to "test locally" due to Rust's place in the dependency graph. It's not feasible to bootstrap Rust for me <lfam>I'm going to see about setting up the full core-updates CI job, or at least doing something about Rust <apteryx>lfam: yeah it's annoying. I'm tempted to give mrust bootstrap from 1.39 a try <apteryx>but just tempted. I'm swamped with other things already. <lfam>Anything we can do to shorten that bootstrap is worth it <lfam>And if there's no time to fit it into this core-updates cycle, we can always have a rust-updates branch later <lfam>Since it's only a bootstrap chain, we can be confident that dependents will keep working <Jorge[m]>Hello, how can it be the order to replace a windows manager for example to herbstloftwm? <nanounanue>Yesterday I pulled from the guix channel, and my Emacs started to throw a weird error when trying to use `map-merge` from `map.el`. <nanounanue>This error is independent if I run it from my Emacs configuration or using the flag (-Q) <nanounanue>I reported this error in the Emacs channel (#emacs). The error happens even in simple code as: (map-merge 'list '((a . 1)) '((a . 2))) <nanounanue>(Apparently, and error in the guix manual in DE language) <lfam>I'm trying `guix pull` know to see if I can reproduce <lfam>I'm not using emacs or that 3rd-party channel 'flat' that you are using, but I can check if the manual builds for me <lfam>nanounanue: Can you sahre the results of `guix pull --list-generations`? <lfam>I'm still waiting for the build to finish here, but it's not a good sign that it stopped building on CI <lfam>roptat: Maybe one of the recent opam or dune changes broke building the manual ^ <nanounanue>I will wait, and then I will check the error in emacs. I will come back and report. <lfam>Okay. For the emacs thing, try again without the extra channels <lfam>The 'flat' channel is about emacs, right? <lfam>Then I don't know. I'm not using emacs so it's hard for me to investigate. But many other people here use emacs! <nanounanue>but you are right, maybe is colliding or something? <nanounanue>I will come back later, need to read a story to my son <lfam>It's a question for the emacs masters :) <lfam>Okay, we will look into the manual building bug *lfam looks for `guix pull --bisect` <lfam>It's slow to build this guix-translated-texinfo.drv <lfam>I wonder why Guix is so slow to update Git repos while pulling. It seems to be much slower than normal `git` <lfam>I see. Thanks for the reference! <iskarian>There may also be some overhead from the guile-git bindings (callbacks and so forth) <lfam>Yeah, I'm wondering if there's anything we can do in the Guile portions <the_tubular>iskarian: that's a good read, I had the same question <iskarian>without having personal experience with either, I suspect the speed difference between libgit2 and git largely come down to cache and i/o efficiency <SVS>Hi! Which files do I need load with loadkeys? Aside from my country's keyboard keys. <lfam>The issue I'm seeing is while updating an already fetch repo <lfam>Like, it's rare that I clone new repos <the_tubular>Well, at least we can be pretty confident it's not guix's fault. <KittyOwO[m]>Where can I figure out what use-modules and use-service-modules in the config are actually loading up? (Started with a "g"ui generated config and have been working from there) <apteryx>all they do is append the symbol to the module name like so (gnu packages X) or (gnu services Y) <KittyOwO[m]>ye, but, for example, what would gnu packages "graphics" even contain, for an example? <lfam>It contains package definitions for software related to 'graphics' <apteryx>KittyOwO[m]: yes, you'll quickly find that most question like this are better answered by the source directly, so grab a copy :-) <KittyOwO[m]>ah, thanks uwu, I was wondering where I could find that uwu <the_tubular>I guix pull and I've been stuck at : building /gnu/store/4kkh1wx6f3qml9r76n2zi43bjs7vascd-guix-translated-texinfo.drv... for 10 minutes ... <the_tubular>2 Vms are hanged on the same package ... Is it building for anyone else ? <vivien>I can pull commit --commit=b7d1698f7fb1f4119d29951d0059b26770e2a853 <atuin>Hi, `guix pull` seems to hang when building guix-translated-texinfo derivation, anyone having same issue? <moshy>Greetings. I notice guix-translated-texinfo is taking a long time to build, a major update by chance? <atuin>moshy I have asked same thing minutes before :D <moshy>I see, literally just logged. Didn't know if this chan had chat logs <atuin>and when building with debug=5 the derivation simply fails :D <atuin>with the error: `bind mounting `/dev/full' to `/gnu/store/4kkh1wx6f3qml9r76n2zi43bjs7vascd-guix-translated-texinfo.drv.chroot/dev/full` <moshy>it doesn't just hang by chance, using up cpu? <atuin>yes, it hangs when building wit debug < 4, it crashes with debug >= 4 <moshy>been running literally 50 minutes <atuin>yes, I think it's just consuming CPU ... <atuin>dunno id there is a workaround to update guix itself if pull does not work <moshy>maybe it's /dev/full creating an endless write loop <atuin>mmmm maybe it's related, yes <futurile>Hi - I'm just getting started with guix. I'm trying to build a package locally from the source package defined in the guix repos. I did `guix build ed` and rather than build the package it used a substitution from the CI system. I need to remove the package from the store so I can retry building it. But, I can't figure out how to remove the package from the package store: if I try `guix remove ed` it <futurile>correctly says I haven't installed it, I tried it with the path `guix remove /gnu/store/ah51j7kj9xk5r3xqp77n2d7hhmy82ms3-ed-1.16` but that errors. Is there a way to do this, or have I got a bad mental model? <atuin>futurile: did you try with `--no-substitutes`? <slyfox>'guix build --check ed' should also do it <futurile>no - I figured I had to remove it before I tried again - I'll try that now <futurile>--no-substitutes doesn't work - guess it's a 'complted build' so doesn't think it has to do it again. Ah --check ed works. <futurile>OK, so how should I remove that 'derivation'? from the store? is 'guix gc' the only way? <slyfox>you can also 'guix gc' the unused local fetched substitutions (might delete A Lot) <slyfox>'guix gc' help says 'guix gc /store/path' might be a way to exict one entry safely <moshy>thing with doing 'guix gc' alone, can break the system in some ways. ended up losing all my icecat addons, needing to delete .mozilla to fix <atuin>is there a way to get the output from a derivation? I really would like to see what's doing the guix-translated-texinfo one <atuin>What's the difference between `guix pull --commit=XXXX` and using time-machine? <slyfox>looking at raw process tree might show it as well. for me perl uses 100% CPU on the following command: /bin/sh '/tmp/portage-tmpdir/portage/sys-apps/guix-9999/work/guix-9999/build-aux/missing' po4a-translate -M UTF-8 -L UTF-8 -k 0 -f texinfo -m "doc/guix.texi" -p "po/doc/guix-manual.es.po" -l "doc/guix.es.texi.tmp" <atuin>I guess time-machine does not install the guix profile <atuin>slyfox, yeah i have same (4 processes though) <atuin>but it has been running for 40 mins :D Is not too much that? <slyfox>i think that script is supposed to run for seconds, not hours <atuin>yes, something is weird there <atuin>also the error when running in debug mode ... <slyfox>something recent in doc/guix.texi managed to break it <atuin>I'm trying to run pull on different commits to see when it breaks <atuin>4 commits to that file since yesterday ... <atuin>mmm what command did you run when doing the bisect? <slyfox>I ran 'po4a-translate -d -M UTF-8 -L UTF-8 -k 0 -f texinfo -m "doc/guix.texi" -p "po/doc/guix-manual.de.po" -l "doc/guix.de.texi.tmp"' <slyfox>in a good case it runs for 6 seconds <slyfox>in bad case it hangs up for longer <atuin>ahhh nice the real command that hangs :) <atuin>I was doing git pull and ofc it was taking ages :D <the_tubular>What is : uix-translated-texinfo.drv anyway exactly ? <slyfox>from what i understand it's 'info guix' translations. <slyfox>if you need to process text (and in this case input is .texi markup), the text processor might have pathological exponential behaviour <the_tubular>I'll pretend like I know what "pathological exponential behaviour" means :P <roptat>gah, I see there's a fix sent to the ml <dstolfa>slyfox: what's the case that causes it in texi? i don't really know much about texi, but the fact that something is exponential makes me worried lol <slyfox>dstolfa: i have no idea myself. i would guess that po4a-translate tries to handle nesting for @{...} constructs and does not like when they are unclosed on a single line. <roptat>po4a has a few bugs with texinfo <roptat>if any of you knows perl and wants to have a look... <roptat>I pushed the patch btw, it should be fine now <mfg>has anyone ever had a look at #45692? <atuin>roptat, slyfox: now it works! thanks <atuin>I'm trying to understand how guix prepares the initrd and how the boot is done. Where does it generate the arguments for the kernel? <atuin>ahh seems it's on `bootable-kernel-arguments` :) <vldn>has someone a simple example of a compiled and loaded linux-kernel module? <vldn>i'd like to build a package for the CP210x usb-serial driver to program my microcontroller <vldn>or maybe better, whats the right patch for KDIR? :D <vldn>the makefile has atm "KDIR = /lib/modules/'uname -r'/build" <roptat>vldn, maybe look at existing module packages, such as vhba-module <vldn>aaah there is a linux-module-build-system <roptat>hopefully, the build system can do all the stuff for you :) <vldn>mh an idea how to disable "cc1: some warnings beeing treated as errors"? <roptat>you need to pass -Wnoerror to the compiler I think <ft>Though, gcc doesn't enable any warnings as errors by default. Not sure what linux-module-build-system enables. <bost>Hi. Is there any `partial` function in Guile? For partial function application? <ft>Functions in scheme aren't curried by default. Guile has the (ice-9 curried-definitions) module additionally, though. <ft>That allows things like (define ((add a) b) (+ a b)). <excalamus>How do I clean up a build? I'm trying to upgrade a package definition. I made the changes and ran guix build -K --file=myfile.scm. It completed and made an entry in the store. I've tried guix gc -D /gnu/store/snthntshsnth... but it says its not in the store. Is guix gc appropriate here? If so, how do I refernce the store item to remove? <excalamus>Okay, looks like guix gc is what I need. My build won't delete because it's "live" (shows up in --list-live). Things in the store are live when they are reachable from a root. How do I find which root my build is under? <excalamus>guix gc --list-roots just gives 134 symlinks <excalamus>I see that the roots correspond to generations. I'm currently on gen 80. My build doesn't appear to be part of the generation; at least it doesn't appear in guix package --list-generations <excalamus>Yeah checking out the link, to the generation, the bin doesn't contain my build <alice[m]>hi, anyone knows of some intro to devops done with guix? that might be a bit vague, here's what i'd like to do, if possible: <alice[m]>suppose i have a guix server somewhere (e.g. a vps where i've installed a guix image already) <alice[m]>and suppose i want to install and launch a service, e.g. nextcloud or mastodon; in principle, is that something that can be scripted and done via guix (e.g. guix deploy?) <roptat>excalamus, it can also be a reference that's not part of the profile <roptat>like, glibc is live because it's referenced by binaries from your profile, but there's no lib/libc.so unless you explicitely add glibc to the profile <roptat>you can try guix gc -R (--recursive) with a profile directory to see which are all the references reachable from that profile <roptat>there's also guix gc --referrers, but I've never understood how it worked exactly <excalamus>roptat, hmm, okay. Sounds like I'm on the right track. Checking guix gc --references showed something similar. <slyfox>is there a config file place in ~/ where i could set default arguments for 'guix build'? I'm interested in --cores= --max-jobs= and --load-path= <leoprikler>slyfox: .bashrc "alias guix=~/.config/guix/current/bin/guix --cores=..." <slyfox>Yeah. i'm a bit worried that it does not translate well to 'guix environment' and './pre-inst-env ...' calls of the same. nix has '/etc/nix/nix.conf' and '~/.config/nix/nix.conf' for some of these. <excalamus>roptat, there's a emacs command guix-store-item which can give information about store items. For better or worse, it has a button to delete. Even though it calls gc under the hood...it actually deleted the file I specified. I didn't expect it to work. I expect that it will cause me problems... <leoprikler>well, if it just deleted the file, then it was probably fine to do so, no? <excalamus>The info page says, "removing files or directories manually may break it beyond repair!" <excalamus>I've saved all my shell output so I have a list of all the returns fro guix gc --references and guix gc --recursive. One way forward might be to use the guix-store-item command to remove each of these manually. <excalamus>All this feels obtuse. But it's all I can find in the documentation <excalamus>I assume there's some bookkeeping going on. So, yeah, since the guix-store-item-delete command (which the button) calls gc, that should be taken care of. <apteryx>excalamus: why would you micro-manage your store items instead of letting 'guix gc' taking care of removing the cruft? that's what it's made for. <excalamus>apteryx, great question. Because running guix gc --delete, the only option in the documentation I could find to remove items from the store, returned an error. I don't have the log output for the error <excalamus>I deduced it was because the file was live. The file appeared in guix gc --list-live and the docs said --delete wouldn't work for those. <apteryx>if you run just 'guix gc', it'll delete everything it can (which are not referenced by things in profile, e.g. not 'live'). <excalamus>Really? The file I just deleted had appeared in the --list-live output. Wouldn't that mean it's live and wouldn't be gc'd? (assuming I hadn't deleted it) <apteryx>so if you want to retrieve as much disk space as possible, what is recommended is to first delete the generations of both your user and system profiles (e.g. 'guix package --delete-generations' and 'sudo guix system delete-generations' and then run 'guix gc' <apteryx>guix gc -d or --delete shouldn't delete live things; if it did, that's a bug <apteryx>are you sure it was live? are you sure it's gone? <apteryx>if I try to delete the Emacs I'm currently using, I get: guix gc: error: cannot delete path `/gnu/store/y10d0fashc4nb3h0yz7qr1ildg3pdc9r-emacs-27.2' since it is still alive <apteryx>(that's with 'guix gc -D /gnu/store/y10d0fashc4nb3h0yz7qr1ildg3pdc9r-emacs-27.2/bin/emacs' <excalamus>No, I'm not sure. I don't have the shell output fro that, so I am probably confused about that <excalamus>There are still items from the build remaining. Running guix gc -D gives this: <excalamus>ahab@pequod ~$ guix gc -D /gnu/store/ijfrdwrlrrkkhvqc83p19byg4smf7anm-plover-4.0.0.dev10 <excalamus>guix gc: error: cannot delete path `/gnu/store/ijfrdwrlrrkkhvqc83p19byg4smf7anm-plover-4.0.0.dev10' since it is still alive <excalamus>So, it's not live in the sense of running. But live for gc means some kind of path reference <excalamus>From this, I conclude that the file I deleted was considered live, too <zacchae[m]>I'm trying to build an image for my raspberry pi (ARMv8), so I ran `guix system image conf.scm --image-type=arm64-raw --volatile`. However, it fails with: <zacchae[m]>guix system: error: gnu/packages/syncthing.scm:45:2: syncthing@1.15.1: build system `go' does not support cross builds <zacchae[m]>is there some reason go will not compile for arm64? <apteryx>it means someone would need to add cross-compilation support to the go-build-system <apteryx>as an alternative, you could try using --system alongside QEMU + binfmt (it's surprisingly easy to get it going on a Guix System) <apteryx>by using --system=aarch64-linux, it should make your host appear as a native ARM 64 bit machine, and build directly for the selected target. <apteryx>there are caveats though; QEMU is far from perfect and sometimes you may get build errors (often in test suite) due to the QEMU memory model not matching the actual hardware. <apteryx>another way would be to connect some other (more powerful?) native ARM 64 bits machine and configure it as an offload machine to build the software natively. <zacchae[m]>So cross-compiling is not the same as compiling for another architecture? weird. <zacchae[m]>As for me adding cross-compilation for go, I would want a working base arm64 install before trying to develop for it. <zacchae[m]>So I can avoid cross-compiling by setting up a QEMU with aarch64 and compiling directly. Cool. <zacchae[m]>This would be my first ARM machine with guix, so I have no other arm64 machine to offload to. <GNUtoo>zacchae[m]: on x86_64 you probably can also compile for i686 without cross compiling, so while you need 32bit libraries and so on, the host computer can run tests and 33bit programs <GNUtoo>If I cross compile for armhf for instance, I need an emulator to run the ARM code <GNUtoo>And for Windows even if Wine Is Not an Emulator, you can only run the cross compiled code with wine <GNUtoo>Though I've not verified in the code that Guix already behaves like that but it makes sense for me *GNUtoo dreams of a world where Guix can cross compile to every major OS target, and so people would port their software to Guix because of that + all the on making it bootstrapable <GNUtoo>(And make it FSDG compliant along the way) <slyfox>that would require some extra work to make it happen :) <excalamus>For posterity, it looks like I was able to clean up my store by clearing out previous system profiles and package generations. I think it was apteryx who suggested this. Thanks! <GNUtoo>btw, I've things like that: "Unbound variable: %current-target-system", when trying to disable tests of a package with #:tests? (let ((system (or (%current-target-system) (%current-system)))) (string-prefix? "x86_64-linux" system)) <GNUtoo>I've asked here the other day and I was told that I needed to do something special to those variables <lispmacs>can I specify a particular linux-libre version in my system config? <excalamus>Looks like they're trying to use a specific version of linux-libre-headers ***emacsoma1 is now known as emacsomancer
<lfam>Yes, something like (kernel linux-libre-5.4) is correct <lfam>We have packages for all the long-term and stable kernels