IRC channel logs

2022-12-06.log

back to list of logs

<ieure>mekeor[m], I'm inside the graphical installer, to what would I pass that argument?
<mekeor[m]>ieure: ... because i don't know the value of the default substitute url list. in particular, if it includes bordeaux.
<mekeor[m]>ieure: does your installer have an internet connection? that might be a reason for a substitute server to time-out.
<mekeor[m]>ieure: afaik, the graphical installer does not support specifying a list of substitute servers.
<ieure>mekeor[m], Yes, it downloaded hundreds of megs of stuff before falling over, then corrupting some SQLite database and requiring me to start the process over again.
<ieure>I see it downloading from bordeaux.guix.gnu.org.
<mekeor[m]>corrupting an sqlite database sounds really bad :(
<ieure> https://i.ibb.co/KjxMDpP/image.png
<ieure>Third time's the charm?
<ieure>sigh
<mekeor[m]>ieure: what's the context? which image? which command?
<ieure>mekeor[m], I'm using the 1.4.0rc1 installer, graphical mode, inside a VM. I don't know what command the installer is running.
<ieure>I just know that whatever it's doing fails a different way every time I try it.
<ieure>This is in the final install-the-system step, after I've partitioned stuff and picked what kind of system I want.
<ieure>Nope, similar failure again.
<ieure> https://i.ibb.co/pwvxYdY/image.png
<ieure>After hitting enter, I get an option to retry, when I select that, this is what I see: https://i.ibb.co/rQLbXMV/image.png
<ieure>And I can't proceed and have to kill the VM, delete the disk image, and try again.
<ieure>But after three tries and three failures, I'm not inclined to continue tilting at the Guix windmill.
<ieure>New user feedback: It's inordinately difficult to actually install Guix, even in the simplest possible case of a VM running on my computer.
<mekeor[m]>ieure: all errors point to data corruption. could something be wrong with your vm setup?
<mekeor[m]>ieure: you're running 1.4.0rc1, which is a release-candidate, open for testing. so, you shoudl expect bugs.
<ieure>mekeor[m], But I was told that the 1.3.0 release is "old" and I should use 1.4.0rc1?
<ieure>mekeor[m], I have no idea if there's something wrong with my VM setup, but I think it's unlikely.
<mekeor[m]>ieure: you could also go back to your old approach, set up a vm with the stable 1.3 release, then run "guix system describe", which will print the path to the active system declaration. you can then create a copy of that system-declaration, slightly modify it to include an ssh-daemon, then reconfigure the system...
<jlicht>ieure: all of those "helpful" errors indicate that your connection to the substitute servers is pretty unreliable.
<ieure>I guess what I keep wondering is: is this really the process a new user has to follow to get a working install?
<ieure>jlicht, I don't know what to tell you. I'm on a 100mbit cable connection. Had zero issues downloading the VM or installer image.
<jlicht>note that I did not imply the issue is on your end ;) ieure
<jlicht>fwiw, I don't believe you need to salt the fields and burn the entire VM each time. Where did you get the instructions to do that?
<mekeor[m]>personally, i just used the (latest, iirc) system installation image to install guix system on my computer. it worked just fine.
<ieure>jlicht, Nobody instructed me to wipe the disk image, but after a failure complaining of a corrupt SQLite database, and restarting the installer also didn't work, it seemed prudent to make sure no ill effects from the prior attempts leaked to the next.
<ieure>mekeor[m], Well, that's what I'm trying, and it doesn't.
<jlicht>and (I might be wrong here), at the stage where the installer is running these commands, I'd _hope_ that switching to tty3 in the VM, and running `guix system init /etc/config.scm /mnt' would 'retry'
<ieure>Not saying it didn't work for you, but it's most definitely not working for me.
<ieure>Right, but I'm a new user. I have no way of knowing those things.
<ieure>I've been using Linux since the 1990s and have built multiple distros from scratch... but I'm a total dumbass when it comes to anything about Guix.
<jlicht>It's in the manual, conveniently available on tty2. Not to say that anyone should know it by heart or something, as I clearly don't
<ieure>Yes, but I'd also have to know the command to run. I mean, I get it. If a Debian install fails, I can fix it, because I've been using Debian for decades.
<jlicht>Have you tried the via manual installation method?
<jlicht>s/the via/via the/
<ieure>No, it seems like it's for people who know what they're doing (= not me).
<jlicht>If you're comfortable with GNU/Linux (or just patient + curious), that's the install method I would recommend, at least the first time
<podiki[m]>you can also use guix as a package manager on another distro and also create system images to boot (say, from a usb) direclty :)
<mekeor[m]>ieure: i just tried to boot guix system into a qemu vm. it worked! here's how i did it:
<mekeor[m]>ieure: 1: download "GNU Guix 1.3.0 QEMU Image" from https://guix.gnu.org/en/download/
<mekeor[m]>ieure: 2: following https://guix.gnu.org/en/manual/en/html_node/Running-Guix-in-a-VM.html, run "qemu-system-x86_64 -nic user,model=virtio-net-pci -enable-kvm -m 1024 -device virtio-blk,drive=myhd -drive if=none,file=/path/to/guix-system-vm-image-1.3.0.x86_64-linux.qcow2,id=myhd"
<mekeor[m]>(that will boot into a guix system with xfce.)
<podiki[m]>seeing as 1.4.0 has a release candidate, good to test that especially if it fails in some way where 1.3.0 does not
<mekeor[m]>ieure: 3: you can then start a terminal emulator (inside guix system, running inside qemu). there, you can run "guix system describe" which will print the path to the current system-declaration. you copy that file and modify it to include an ssh-daemon
<mekeor[m]>podiki: sure, unless you already made too many bad experiences with guix so far :D
<mekeor[m]>ieure: alternatively, you could also first install guix on your foreign distro. then, write a system.scm and proceed with following "10.16.1 Connecting Through SSH" https://guix.gnu.org/en/manual/en/html_node/Running-Guix-in-a-VM.html
<ieure>mekeor[m], I successfully booted the QEMU image in a VM; that's not the problem I came in here to raise/solve.
<ieure>Okay, I have an install running in a VM, and it only took two hours to make work.
<mekeor[m]>ieure: right, sorry!
<jlicht>the real guix was the friends we made along the way
<mekeor[m]>ieure: how did you succeed?
<ieure>mekeor[m], Insanity, I kept doing the same thing and expecting different results, which eventually happened.
<ieure>Another thing I recall being not well documented from my last go at this: How can I make a Guix package repository?
<mekeor[m]>ieure: you create a channel. it's just a git repository containing guile-modules which export guix packages.
<mekeor[m]>ieure: create a local git repository. there, write a .scm-file, exporting a guix-package. then, add something like (channel (name 'my-channel) (branch "my-branch") (url "/path/to/my/channel")) into the list of channels inside your ~/.config/guix/channel.scm
<ieure>Okay. I need to learn more Guile to effect this, I think. Most of my Lisp hacking has been Emacs Lisp/Clojure/CL.
<cbwang>Are there any ongoing projects trying to bootstrap Android SDK? Is it even possible doing so? I guess it might be quite useful because once we've done that we might be able to bootstrap GrapheneOS
<mekeor[m]>ieure: i think this might be one minimal package declaration: https://paste.rs/tob.scm
<ieure>Thanks, that's helpful.
<mekeor[m]>(... assuming the file is located at /path/to/channel-repositor/channel/packages/test.scm)
<Andronikos>cbwang: Yesterday they told me this would require tons of time. So I would say it tends to never since it is kinda hacky as well.
<Gooberpatrol66>is it possible to get a root shell with a user's guix? like if i run "sudo guix" and then "sudo -s" + "guix" it uses the same guix version
<Gooberpatrol66>i mean, it doesn't use the same version, but i want it to
<jlicht>Gooberpatrol66: I always use `sudo -E guix ...', but I'm no sudo-expert. Does that work for you?
<oriansj>I am going to be honest, I am really not liking the vary sparse documentation around static IP addresses
<Gooberpatrol66>jlicht: i tried that once and it broke my guix. it gave some files the wrong permission or something.
<Gooberpatrol66>made it impossible to install anything until i fixed it
<podiki[m]>why do you need sudo guix? typically only for system reconfigure
<oriansj>why would the networking service be created but not start on boot?
<oriansj>would (requirement '(udev)) mean I need udev to be started first?
<jlicht>oriansj: any shepherd service that has (provision '(udev _ ...)) would do the trick, but yes
<jgart[m]>thought guixers might find this interesting: https://todo.sr.ht/~whereiseveryone/guixrus/1069
<the_tubular95>Mind explaining a bit jgart[m] ?
<the_tubular95>I just see links to container and void linux stuff
<nlspaeth>Hi. With systemd it is possible to use a command like`systemd-run --scope -p MemoryMax=250M -p MemoryHigh=200M /path/to/program/to/use` to limit the resource usage of a process. Does guix provide anything like this, or will installing systemd for this purpose cause any conflicts?
<podiki[m]>I don't know of anything like that and there is no systemd on guix system (if you have guix as a package manager on another distro, then you would have systemd if that distro does)
<nlspaeth>Okay, it looks like I'll have to try using cgroups directly. I'm noticing that guix is has cgroups v1 (not v2) enabled by default. Is this a requirement, or could I safely enable v2? (I'm using Guix as my base system, btw)
<unmatched-paren>morning guix :)
<sneek>zamfofex: wb!!
<zamfofex>sneek: 💞 botsnack
<sneek>:)
<raghavgururajan> Hello Guix!
<unmatched-paren>raghavgururajan: hello!
<raghavgururajan>Congrats everyone on v1.4.0 release! :-)
<haugh>hayo
<unmatched-paren>raghavgururajan: not quite yet ;)
<raghavgururajan>I saw new tag in the log.
<raghavgururajan>release tag
<raghavgururajan>in git log
<unmatched-paren>we're doing release candidates at the moment
<unmatched-paren>that version-1.4.0 is simply the branch it's being done on
<unmatched-paren>not the actual tag
<civodul>Hello Guix!
<xd1le>o/
<reyman>HI !
<reyman>I have an error at the end of compilation of rust Deno, but if i build using -K option, error appear, i'm going to /tmp and relaunch the build, the error don't appear and the compilation end.
<reyman>strange
<reyman>i have an error : clang++: error: no such file or directory: 'obj/v8/libv8_base_without_compiler.a'
<reyman>but if i look to the history of compilation :
<reyman> [1905/1922] AR obj/v8/libv8_base_without_compiler.a
<reyman>the lib is well compiled
<zamfofex>Is the file actually there after ‘--keep-failed’?
<reyman>i need to relaunch the compile because my last run is without -K
<reyman>but yesterday i finalize the compilation with the same error
<reyman>the trace is not clear, the panic error is an assertion failed
<reyman> thread 'main' panicked at 'assertion failed: ninja(&gn_out_dir, maybe_env).arg(target).status().unwrap().success()', /tmp/guix-build-rust-deno-1.25.2.drv-0/deno-1.25.2/guix-vendor/rust-v8-0.49.0.tar.xz/build.rs:695:3
<reyman>and the and the script indicate :
<reyman>[1913/1922] LINK ./mksnapshot FAILED: mksnapshot
<reyman>ython "../../../guix-vendor/rust-v8-0.49.0.tar.xz/build/toolchain/gcc_link_wrapper.py" --output="./mksnapshot" -- ../../../../../../gnu/store/ampl0am1v6g6h1x7c4cjd6qp3aj7pl20-clang-toolchain-14.0.6/bin/clang++ -pie -fuse-ld=lld -Wl,--fatal-warnings -Wl,--build-id -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--icf=all -Wl,
<reyman>--color-diagnostics -Wl,--no-call-graph-profile-sort -m64 -no-canonical-prefixes -rdynamic -Wl,-z,defs -Wl,--as-needed -nostdlib++ -pie -Wl,--disable-new-dtags -Wl,-O2 -Wl,--gc-sections -o "./mksnapshot" -Wl,--start-group @"./mksnapshot.rsp" -Wl,--end-group -ldl -lpthread -lrt
<reyman> clang++: error: no such file or directory: 'obj/v8/libv8_base_without_compiler.a'
<reyman>i already remove an assert that don't work well in the build script
<zamfofex>civodul: In <https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00088.html>, I just now realized it might have been useful to include GMP’s ‘config.log’ file from ‘--keep-failed’. Does it make sense to send another email?
<reyman>i relaunch with -K to see
<reyman>(waiting 40 min now ...)
<civodul>zamfofex: ah yes, please
<lxsameer>hey folks, I want to configure lxd as part of the `operating-system` should I extend lxd service with a new service?
<cbaines>is there an lxd-service-type yet lxsameer?
<cbaines>I see it's being worked on in https://issues.guix.gnu.org/50133#6
<lxsameer>cbaines: let's assume there is not, should I create a service and extend shaperds ?
<cbaines>I think working on getting a lxd-service in to Guix is the right first step
<darosior>Hello, i'm (still) trying to get a rust toolchain linked against an older glibc (29). One issue i hit is that apparently llvm is linked against the current glibc in Guix (33). I can't find the input to modify in the package definition of llvm to overwrite that: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/llvm.scm#n582. Has someone
<darosior>already hit this? Is llvm special in some sort? Or maybe i'm wrong it gets linked against glibc 33?
<reyman>ok, compilation finish, same error mksnapshot clang ++ no such file or directory, 'obj/v8/libv8_init.a'
<reyman>i verify because i'm running with --keep-failed
<reyman>and this file exist
<reyman>into /tmp/guix-build-rust-deno-1.25.2.drv-0/top/deno-1.25.2/target/release/gn_out/obj/v8
<civodul>reyman: you should never see "/top" here
<civodul>if you do, that's because you're fiddling with the build tree before the build process has completed
<civodul>and that's Strictly Forbidden
<civodul>:-)
<civodul>(i realize this does not help you re v8/clang issues, but hey ;-))
<reyman>ahah :) yep, i have a process that continue to run,
<reyman>libtokio
<civodul>darosior: all the packages in the 'master' branch are linked against glibc 2.33
<reyman>perhaps is that that provoc this fail
<civodul>we switched glibc version in the 'core-updates' branch only
<reyman>so if i cut the process
<reyman>top disapear :)
<reyman>and now i rerun the compilation manually
<darosior>civodul: yeah and i'm trying to use an older glibc, i managed to modify the rust inputs with a custom "make-gcc-toolchain" but i can't find how to do the same for llvm.
<civodul>darosior: oh i see; i think there's a similar make-clang-toolchain, but maybe it's not as flexible?
<darosior>civodul: there is. However the rust package directly depends on llvm, not clang. Would you happen to know what input makes it use glibc 2.33 (or any glibc at all)?
<darosior>Maybe giving more info could help. The issue i hit is that the build of the rustc-1.54 derivation fails with a couple lines like:
<darosior>ld: /gnu/store/ma1542lj666z2njy3g08wi4gzqa2bx40-llvm-12.0.1/lib/libLLVMSupport.so: undefined reference to `lstat@GLIBC_2.33'
<apteryx>efraim: I forgot about the monthly meeting, apologies!
<apteryx>nckx: ^
<mirai>exactly what provides 'modprobe' command?
<mirai>kmod or module-init-tools ?
<civodul>darosior: glibc is an "implicit input" provided by gnu-build-system, cmake-build-system, etc.: https://guix.gnu.org/manual/devel/en/html_node/Build-Systems.html
<apteryx>mirai: realpath `which modprobe` says /gnu/store/vh4g56m35wwlfg300s4qafykxjy09511-kmod-29/bin/kmod
<mirai>apteryx: guix search modprobe would suggest module-init-tools
<darosior>civodul: thanks. I'll look into it
<civodul>darosior: assuming you define a glibc@2.35 package (say), you should be able to do: guix build rust --with-graft=glibc@2.33=glibc@2.35
<mirai>but looking at kmod package it's also creating symlinks for modprobe
<darosior>oO
<darosior>Ok, very interesting. Thanks!
<darosior>(I use a manifest for a guix shell for a reproducible computation but i guess it's similar)
<lxsameer>hey folks, do you know any service that I can use as a good example to write my own service? the docs are not clear enough
<cbaines>lxsameer, what are you thinking of writing a service for?
<mirai>lxsameer: depends how exotic your service is
<lxsameer>I want to configure lxd in a certain way
<mirai>you should start with services using define-configuration
<cbaines>lxsameer, mirai, I'd start with the already in progress service for lxd
<mirai>the manual example at (Complex Configurations) is an adequate step
<cbaines>apteryx, do you know if berlin is good to reconfigure currently?
<lxsameer>cbaines: that's not an option, I don't know how to write a service to begin with, it will only make me more confused
<mirai>cbaines: oh, didn't know that there's already groundwork done
<civodul>darosior: yes, manifests can also specify package transformations; see "guix shell ... --export-manifest"
<lxsameer>mirai: to begin with I'd like to understand the process
<apteryx>cbaines: as good as ever, but in case of boot problems we do not have a 2nd machine to reach it, so we'll depend on rekado
<cbaines>lxsameer, trying to use the service that's already been written should help with understanding the process
<cbaines>apteryx, cool, I'll give it a go, I'd like to see if I can update Mumi
<lxsameer>cbaines: that's why I'm asking for a good service to look at as an example
<cbaines>lxsameer, I think I fail to see why the lxd service is not a candidate to look at, especially since that's what you're wanting a service for?
<mirai>apteryx: this module-init-tools package and kmod package seem to provide the same tools
<lxsameer>cbaines: I looked at it and felt, ok I need to know more about the services for this to make sense
<cbaines>lxsameer, ok, which bits were you confused by?
<mirai>the description seems to suggest kmod is an alternative to module-init-tools
<lxsameer>cbaines: to begin with, why we need this service at all? for example right now, lxd will start on it's own with the default configuration
<lxsameer>but this is kinda against what i expected because it puts the system in a state that is not part of my operating-system definition
<lxsameer>cbaines: second issue is service-extension in general
<cbaines>lxsameer, so the service does a number of things, it specifies that there should be a lxd group, creates a /var/log/lxd directory and has the shepherd run lxd
<apteryx>civodul: in guix/build-systems/gnu.scm, "When not cross-compiling, ensure implicit inputs come last". Does that mean adding a different glibc in native-inputs would work, just as adding a gcc-7 or different version works for native compilation?
<civodul>apteryx: glibc is special because the compiler explicitly refers to it, notably in its default "spec"
<lxsameer>is it possible to define an extra channel as part of the `operating-system` ? with `guix deploy` in mind
<civodul>so simply adding a new libc to the inputs is not enough
<cbaines>woo, reconfiguring berlin seemed to go smoothly, and now issues.guix.gnu.org is showing badges from qa.guix.gnu.org :) (e.g. https://issues.guix.gnu.org/59851 )
<apteryx>civodul: I see. I made a change (in a guix/build-systems/gnu2.scm) to have a cross-compiler inferred from the native-inputs provided gcc, glibc, binutils and linux-libre-kernel-headers packages. That appears to work for this use case, but wouldn't (completely) work for the native use case.
<apteryx>It'd be nice to have different 'toolchains' for embedded development, and be able to declare the toolchain at the package level
<apteryx>cbaines: awesome!
<lxsameer>b
<apteryx>cbaines: it's exciting to see the culmination of your work on the data service, with the beginning of integration in other guix components
<civodul>cbaines: yay, nice!
<cbaines>apteryx, indeed, it took a while, but it's really nice to have multiple things (qa.guix.gnu.org and packages.guix.gnu.org) using the data service
<civodul>apteryx: check out package-with-c-toolchain, it should come in handy
<reyman>hum manually the compilation finish, so the problem is more linked to path
<apteryx>but this can't be used at the level of a guix package (say, in guix proper or in a channel), right?
<apteryx>civodul: also, would it work for cross-compilation?
<gabber>how can i build a hidden package? i'm in the process of bumping mbedtls but there's this comment about the hidden package mbedtls-for-hiawatha breaking..
<apteryx>civodul: my approach could work for native compilation too; so far I've made standard-cross-compilation optionally take as input gcc, binutils, libc, linux-libre-headers and return a custom cross toolchain from that
<civodul>apteryx: package-with-c-toolchain currently is for native compilation
<apteryx>here's the modifications I've made so far: https://paste.debian.net/1263092/
<apteryx>most changes went in standard-cross-packages2 and lower
<civodul>apteryx: honestly, i don't think we're going to come up with a solution in an IRC discussion
<civodul>the problem is that there are lots of ramifications
<civodul>in particular, it's performance critical code (due to memoization)
<civodul>memoization on several arguments isn't super efficient, it's costly memory-wise
<civodul>and then in terms of packaging, it's easy to introduce build issues
<civodul>i agree it would be good to provide flexibility on the toolchain being used
<civodul>that's why i worked on package-with-c-toolchain and --with-c-toolchain actually
<civodul>that level of flexibility for cross-compilation would be great
<apteryx>OK; I'm just unsure how these transformation options fit outside of end users experiments. Say we want to offer a variant of linux-libre for an embedded board in Guix that requires an ancient version gcc toolchain to be built; can we use the transformations in (gnu packages linux) to define such package?
<apteryx>also currently we allow the use of e.g., 'gcc-9' in native inputs to build packages natively with older GCCs; but this breaks cross-compilation because the inferred cross toolchain doesn't honor GCC-9 and uses the default (GCC 10).
<apteryx>I'll keep hacking on this experimental change and see if it really works (it seems too, but I've given it limited testing), and then could submit the diff for discussion to guix-devel (it'd have to go in core-updates if it was ever accepted)
<jlicht>do any of the debbugs-{org,gnu}-guix-search work for anyone? I keep getting a SOAP error
<apteryx>I get: soap-invoke-internal: SOAP error: "soap:Server", "can't get http://localhost:1978/node/bts/search: 500 Can't connect to localhost:1978 at /usr/share/perl5/Debbugs/SOAP.pm line 444
<jlicht>good to know I'm not crazy, or in good company at least :)
<apteryx>hehe
<gabber>how can i build a (hidden-) package from the REPL? which function corresponds to the `guix build` command-line invocation?
<apteryx>there's 'build-package' from (guix scripts), IIRC
<civodul>gabber: at the REPL, you can use ",build": https://guix.gnu.org/manual/devel/en/html_node/Using-Guix-Interactively.html
<mirai>why is a gexp required for this configure-flags portion? (https://paste.centos.org/view/ca829c3a)
<civodul>mirai: because that code that builds up configure flags is staged for later execution when you actually build the package
<mirai>if I do not use #~ it tries to apply "--enable-all" as if it were ("--enable-all" ...)
<gabber>apteryx, civodul: thanks!
<mirai>civodul: right, thanks
<gabber>if I- in the process of bumping mbedtls version -also need to bump the version of a package relying on mbedtls (namely the hiawatha web server), do I a) create one patch consisting of one commit b) one patchset consisting of two commits or c) create multiple patches with one commit each?
<nckx>gabber: (b) if possible without breaking hiawatha, (a) otherwise.
<apteryx>civodul: here's an example that fails without my change: 'guix build glibc@2.30 --target=arm-linux-gnueabihf' :-)
<gabber>great, thanks! that's what i figured after giving the issue a thorough thought (:
<apteryx>because it's supposed to use gcc-8, not gcc-10
<civodul>ok, i see
<civodul>fail2ban-jail-service is weird; it follows a unique pattern
<apteryx>what do you mean?
<a12l>I'm trying to find if libcurl is available in Guix. I don't find it when I look through the results from running guix search libcurl, but it it feels weird that Guix wouldn't have libcurl packaged
<podiki[m]>libcurl is in the curl package
<a12l>Thanks!
<podiki[m]>while some packages will have a separate lib output as opposed to the "out" that has the binaries, mostly they are together rather than a curl and libcurl packages
<a12l>Good to know
<podiki[m]>sorry, I mean packages that have like pkgname:lib and pkgname:out (different outputs), you'll see that sometimes
<podiki[m]>e.g. guix show glib
<podiki[m]>welcome!
<podiki[m]>woah, did QA badges just appear on issues? or did I miss that before?
<apteryx>podiki[m]: yes! cbaines reconfigured berlin earlier to include that improvement!
<podiki[m]>Very nice!
<darosior>What is the "label" supposed to be in the toolchain parameter for package-with-c-toolchain? I'm a bit confused by the documentation example on the hello package.
<nckx>darosior: What's a "label"?
<darosior>nckx: i don't know it's what the doc stated: https://guix.gnu.org/manual/en/html_node/package-Reference.html. But in the end it looks like i could just use whatever.
<darosior>But i'm afraid it's not enough to build a rust toolchain linked to an older glibc: it doesn't rebuild the llvm input of the rust package.
<darosior>The line that was confusing me in the above doc was "toolchain must be a list of inputs (label/package tuples) providing equivalent functionality"
<nckx>That example might be obsolete. ‘Labels’ used to be mandatory in input lists: (inputs `(("libfoo" ,libfoo) ("libbar" ,libbar))).
<nckx>This has been replaced with the simplified ‘new’ (inputs (list libfoo libbar)) style.
<lechner>yay!
<nckx>darosior: <https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system.scm#n105> (package-with- is just a wrapper around this). So it will delete the hard-coded list of packages name'd by toolchain-packages, then append yours. In the vast majority of cases, it won't matter what you label your inputs, but I'd still recommend using those standard names for those packages.
<nckx>darosior: package-with-c-toolchain is not recursive. If you want the change to apply to (a) llvm, you must transform (that) llvm as well.
<nckx>ACTION AFK.
<unmatched-paren>ACTION enters. good evenoon! :)
<darosior>nckx: thanks!
<attila_lendvai>ACTION groans at the clumsy debbugs workflow...
<unmatched-paren>ACTION wonders if changing the package sanitiser to use "foo:output" as the label if the output isn't "out"
<unmatched-paren>...wonders if that would break any packages.
<unmatched-paren>ACTION goes to send a patch and see if QA likes it
<efraim>unmatched-paren: maybe one or two packages, but I have been missing being able to refer to, say, util-linux:lib and not just util-linux
<mirai>how should I handle this kind of nested records (https://paste.centos.org/view/225dc23c) for 'generate-documentation' ?
<mirai>there is more than one field that accepts the same kind of record
<mirai>or should I just generate the documentation for each record type individually
<unmatched-paren>mirai: generate them individually
<unmatched-paren>(i'd argue that you should write them manually, but oh well :))
<mirai>unmatched-paren: the strings are manually written tho
<mirai>that's one of the advantages of define-configuration
<unmatched-paren>mirai: fair enough
<roptat>hi guix!
<unmatched-paren>roptat: evening!
<roptat>there were this thread today on the fediverse: https://framapiaf.org/@Vijaya/109462724681858492 about why "guix pack python" is so big, and in the end, I looked at gcc-lib and glibc to find that most of what they contain is probably not useful at runtime
<roptat>so I'm happily rebuilding a gcc with separate static-lib and shared-lib outputs (instead of just "lib")
<roptat>could reduce the size of gcc-lib by 10-12 MiB I think
<roptat>that is, if it works at all :)
<roptat>ok, failed at first try...
<yarl>Hello guix.
<roptat>yarl, hi :)
<yarl>I have two questions concerning https://qa.guix.gnu.org/issue/59845 : What lines does lints warning are refering to? Sould I resend the complete patch serie (because it's not a single patch, as with the -v VERSION described in the manual)?
<unmatched-paren>yarl: the manual shows how to resend a complete series
<yarl>Also, concerning https://issues.guix.gnu.org/59839 If some commiter saw this I completely messed up my first patch, then my second, sorry about that... Was working on --target (59843) and --system (59839) in parallel.
<yarl>unmatched-paren: Oh, right!
<yarl>I will rework that as soon as I have time.
<roptat>oh, work second try :)
<roptat>or not, shared-lib is almost empty...
<roptat>ah that might be expected for gcc-boot0 actually
<lechner>Hi, I configured buffer-env and created a manifest.scm. How do use it inside Emacs, please? https://amodernist.com/texts/emacs-guix.html
<unmatched-paren>lechner: i think you only need to cd to the directory with the manifest, or edit a file in that directory
<unmatched-paren>i just installed it, but i've yet to test it
<lechner>unmatched-paren / okay, but how do i run it?
<unmatched-paren>lechner: it'll add the necessary environment variables automatically
<lechner>unmatched-paren / do i run the script from geiser?
<unmatched-paren>it implements guix support by default: https://github.com/astoff/buffer-env/blob/main/buffer-env.el#L67
<unmatched-paren>you don't need to do anything, except cd to the directory with the manifest or edit a file in that directory (I think)
<lechner>unmatched-paren / yay, i changed into the folder with Eshell and then run the program there. it is magical. thanks!
<unmatched-paren>lechner: no problem, and now i know that it works ;)
<podiki[m]>mekeor: sure :) but if 1.3.0 works exactly where 1.4.0 didn't, that would be helpful to know, that's all
<apteryx>strange, trying to build an old linux kernel 4.9.11 works from 'guix shell -CD linux-libre', but fails using a package derived from make-linux-libre*.
<apteryx>the main difference I can think of is that in the 'guix shell' the includes are all found under the same location (in the profile union)
<apteryx>so it is less prone to ordering problems
<Tecjor[m]>0.5 MB will be downloaded... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/b22c5e5495e10cc185ed56acef83defa4be576ca>)
<apteryx>re my 4.9.11 build failing, it seems to have to do with the $source/include being added to C_INCLUDE_PATH for some reason (that doesn't happens for our linux-libre package, which is puzzling)
<podiki[m]>something with how the shell makes a profile and search paths then?
<apteryx>hm, it looks like https://issues.guix.gnu.org/44924, but for the linux kernel
<apteryx>and it doesn't happen for the latest linux-libre for some reason
<apteryx>hm, git vs source tarball seems to impact that