IRC channel logs
2023-10-31.log
back to list of logs
<Kolev>Is it normal for Guix loading bars to print to a new line at each change in tmux? <jaeme>Kolev: yeah, it does that sometimes, I don't know what causes it however. <jaeme>It will do it outside of tmux as well on any tty or terminal emulator <Kolev>jaeme, oh, so it's not just a tmux thing. Good. <euouae>I messed up installation of the ESP and I put it in /boot instead of /boot/efi <euouae>should I reinstall guix or is there a way to fix this? <wdkrnls>I'm sad there still isn't a Guix presence in the Americas. <euouae>I'm getting this error after installing guix and running `guix system reconfigure /etc/config.scm` <euouae>`guix system: error: '/gnu/store/...-grub-efi-2.86/sbin/grub-install --boot-directory //boot --botloader-id=Guix --efi-directory //boot/efi' exited with status 1: output follows: <euouae>Installing for x86_64-efi platform. /gnu/store/...-grub-efi-2.86/sbin/grub-install: error: //boot/efi doesn't look like an EFI partition <podiki>euouae: /boot/efi is a formatted FAT? <euouae>mkfs.fat -F32 /dev/nvmen1p1 yeah <euouae>and then I did mount /dev/nvmen1p1 on /mnt/boot/efi <the_tubular>nckhexen, bcachefs seems to have been merge in linux-next <euouae>podiki: how do you do it? when you install guix <podiki>you let the installer partition for you or you did manually? if manually should be I think the same as setting up any other distro's partitions (I had followed some guide for btrfs subvolumes in my case, but /boot was the usual structure) <podiki>i can never remember the proper /boot partitions and efi, I always just look at some reference <euouae>I did a manual installation of the bare-bones.cfg install <euouae>I followed that guide from the link <Kolev>euouae, euaoeuoauaoueoueouaoueidhtns <Kolev>euouae, oh, I thought you Dvorak'd. <podiki>euouae: sorry, don't know more than that. i'm sure someone else will, hopefully just something simple that was missed <podiki>(i did a manual install also, and as i said followed some general partitioning guide, nothing fancy needed. if our docs are missing something that would be good to know) <euouae>should I post what I did on the help mailing list? <podiki>yes that's a good idea (and searching there if you didn't already) <podiki>and/or asking here again when others are around <podiki>sorry I couldn't be of more help! i'm sure we'll get it sorted <vivien>How do I debug a crash into a program that double-forks into a daemon? I’m trying (invoke "gdb" "-ex" "-run" "-ex" "bt" "program") but it does not follow the children. <janneke>hmm, my home reconfigure goes to build lotsa java stuff <janneke>maybe i should pull to an earlier commit? <zamfofex>Hello, everyone! I recently added support for C++ to my “WebAssembly target for Guix” thingie. Unfortunately, daikichi doesn’t seem to be able to be easily compiled, because it makes use of some APIs that don’t seem to be available in WASI. I patched the need for “#include <filesystem>” (see <https://github.com/WebAssembly/wasi-sdk/issues/125>), but it seems I ran into other issues soon thereafter. <zamfofex>I got GMP and fmtlib to compile, though! If anyone (perhaps nckhexen like last time) could suggest me a simple C++ program to try to compile to have something to show, it would be lovely! <mekeor>hello :) does --with-branch only replace (package (source (origin (git-reference (commit THIS))))) or does it overwrite the whole package-source? <jpoiret>mekeor: wdym overwrite the whole package-source? <yaslam>Hello, I was trying to boot the Guix i686 install media on an i386 PC and I get a panic on boot: "cpu isa level is lower than required". Does Guix support i386? Thanks <jpoiret>mekeor: ah, i see what you mean. Yes it does replace the whole source <mekeor>jpoiret: in particular, i got the impression that (package (source (origin (patches THIS)))) is also overridden <jpoiret>you can have a look at L265 of guix/transformations.scm <mekeor>jpoiret: is it a feature or a bug? <mekeor>jpoiret: this makes --with-branch etc unusable when applied on emacs-next which has essential patches in 'source <jpoiret>a feature probably? you can also specify patches with multiple --with-patch= <jpoiret>otherwise you wouldn't be able to reset the list of patches <jpoiret>you can still do the proper thing manually in a manifest <jpoiret>tbh transformations are a quick and dirty way of doing something that should be done using the guile api instead <mekeor>jpoiret: alright. thanks so far! i guess, i could initiate a devel-discussion on package-transformation-cli-args :) <mekeor>(there already have been some conversations about it) <jpoiret>at least it doesn't seem to be documented behavior <yelninei>hi, yesterday i wrote to the help mailing list but my message does not show up on the online archive. What did I do wrong? <yelninei>I've sent my mail to help-guix@gnu.org. (Ive since been able to resolve the issue) <jpoiret>yelninei: if it's your first mail to a ML it will need to be moderated by a human, hence the delay <yelninei>yes its the first mail. that would explain it. My first reaction is just to assume that I did something wrong. Thanks <jpoiret>nckhexen: is there anyone other than you moderating the lists <nckhexen>Yes, but less, and I don't know who's actually active (it's not logged). <nckhexen>If you're the one who mentioned an old openssl test: the package name alone suggests that this might be a 'time bomb' due to an expired test certificate. We don't simulate the past that accurately yet. <nckhexen>But to know for sure we'd need to see the logs that I hope the test suite produces with --keep-failed. <zamfofex>Apparently all simple programs are written in not‐C++. 🙃 <jpoiret>although tbh being able to build GMP is already pretty nice I'd say <zamfofex>jpoiret: Regarding C: Well, yes, but I already had that working last time, so it wouldn’t show anything else new. <nckhexen>I moderadated 2 mails but already forgot what the other one was about 👴 <yelninei>nckhexen booting issues on a thinkpad with luks, but the issue is solved now because the commit that changed the kernel conf got reverted yesterday. But thanks :) <Guest41>hello, i have installled guix with dvorak, but it is still on qwerty. any idea, what the problem is <nckhexen>Uh, OK, please send a follow-up to the list if you have time. <nckhexen>Guest41: Whoever helps you will need more info than that. Sharing your system configuration's always a good start. <zamfofex>Guest41: Have you set the keyboard layout in the system configuration? Which window manager and/or DE are you using? (On X or Wayland?) <nckhexen>yelninei: That commit didn't affect booting, only the display. <yelninei>nckhexen yes will do that later today, when i am back home <yelninei>nckhexen yes i figured that out as well i I could just type the password into the void and it will get accepted but that was not something i tried. It just looks like being stuck on loading the kernel <Guest41>rekado i reinstalled my system now, i think the old kernel version was the problem is, that the version was 5.15 in my config, but the kernel, that is on the usb is on a higher version. <nckhexen>yelninei: We really need to fix this, but it seems like fixing display on some machines breaks it on others. Sorry you got control group'd! <Guest41>rekado so I downgraded with my config and somehow, this was something that was not going down correctly. I will now include the new kernel version in my config <vivien>Dbus-Run-Session May Crash If Too Many XDG_DATA_DIRS Present <Guest41>zamfofex i am using i3 and and i am on X <Guest41> (keyboard-layout (keyboard-layout "us" "dvorak")) <rekado>Guest41: it’s too late now, but reinstallation is generally not required. When Guix is not downloading substitutes you need to check if the substitute server has been authorized. <Guest41>zamfofex it really worked good during installation, but after first use, it did not work <rekado>Reinstallation may only accidentally fix that. <Guest41>rekado okay, thank you anyhow for your patience with me and your effort. I will just try to look which kernel version i now have and update it. My understanding of guix is very low, but I might reexplore that topic on a later occasion. <rekado>Guest41: one thing to look out for is which version of Guix you’re using when reconfiguring <rekado>“sudo guix describe” vs “guix describe” <rekado>just to be sure that you’re not using some older Guix to reconfigure your system <Guest41>rekado is it somehow possible to check which kernel I have installed <nckhexen> /run/current-system/kernel links to the kernel you most recently installed, /run/booted-system/kernel to the one you're running at the moment. <futurile>hmm anyone know how to pass multiple commands to guix shell: I'm trying guix shell --container --nesting --network -- guix pull --commit=XXX && guix describe - I don't get the `guix describe` <Rovanion>futurile: Ugly hack until some more reasonable answer comes along: guix shell --container --nesting --network -- bash -c 'guix pull --commit=XXX && guix describe' <mekeor>when (assoc-ref outputs "out") is executed in a build-systems phase, does it contain the file-path to a temporary directory, where the package is build? <lars80>Does anyone have a working Guix completion setup in Emacs? I have geiser and geiser-guile, and have also tried scheme-mode, but I still don't get completion other than based on words contained in the current buffer. <mekeor>lars80: first, you need a checkout of guix' git repository with built .go files. do you have it? <lars80>I have a checkout, but have not built anything <jpoiret>mekeor: it contains the actual final path <mekeor>lars80: please do the `guix shell -D ...`, `./bootstrap`, `./configure ...`, `make` thing <jpoiret>the package is not being directly built there, but that location is e.g. passed as the --prefix for gnu tools <jpoiret>futurile: && is a bash thing, but `guix shell` invokes the subprocess directly, without going through bash. Rovanion's solution is the proper one i'd say <jpoiret>i also often do that to chain sudo commands <mekeor>jpoiret: in my case, i'm examining this line. it is passed to `emacs-batch-eval`. it must be the actual final path because the emacs-native-compiled .eln-files contain the hash of the compiled .el file-path... <mekeor>i guess Rovanion's solution requires to add 'bash to the list of packages... <jpoiret>let me maybe rephrase a bit: the package is not *always* being built there <jpoiret>you could build it there, but often we build in /tmp and then `make install` will install it to the proper PREFIX, which in our case is #$output <vivien>cbaines_, I think QA applies patches in the order of the author date, so if i rebase and reorder my patches, QA can’t apply them. Here for instance: https://qa.guix.gnu.org/issue/66823 "gnu: Add calls" is the 1st in author date history, but it is number 6/6. However, QA tries to apply it first. <jpoiret>mekeor: i don't get it, sorry. It should really return the final path <mekeor>jpoiret: i'm not sure what i get instead, tbh. i'm trying to understand where the mistake is. but it's kind of hard to debug a build-system <jpoiret>i think this is an instance of the xy problem: what are you trying to fix? <mekeor>jpoiret: emacs packages come with .eln-files, i.e. .el-files that have been native-compiled. each .eln-file-name contain the hash of the respective .el-file. the .eln-files that are build by guix have mismatching .el-file-path-hashes. <nckhexen>Rovanion: That's not a hack, it's the right answer. :) <mekeor>jpoiret: both the path and the content are hashed, in separate hashes <mekeor>jpoiret: {package}-{path-hash}-{content-hash}.eln <jpoiret>how do you test that this doesn't match? just fire up emacs and realize that it won't load the eln? <mekeor>lars80: next, you'll need to use guix-devel-mode and command guix-devel-use-module, bound to C-c . u <mekeor>jpoiret: emacs native-compiles all .el files with no matching .eln when started <vivien>I don’t see how Guix could respect the path hash <vivien>Well, .el files are moved from their original derivation output to, for instance, ~/.guix-profile/share/emacs/, as well as /run/current-system/profile/share/emacs/ <jpoiret>vivien: heh, I guess we can patch emacs to `readlink -f` the paths first then <mekeor>i think it does already? lemme find the code <lars80>mekeor: I built the go files, but completion still doesn't work <mekeor>lars80: did you enable guix-devel-mode? <mekeor>hm, maybe geiser-autodoc-mode? i'm not sure. <lars80>Is anyone up for continuing where mekeor left off, and help me figure out how to get Guix completion in Emacs? <yaslam>Hello. Does Guix support booting on i386. Thanks <lars80>What are you using for writing Guix stuff then? <jpoiret>sneek, later tell mekeor: the .eln file hash problem is due to grafts, grafts change the final output name, but they can't also update the file hashes... we'd need to modify emacs' behavior for this to work <jpoiret>lars80: emacs, i meant i don't use autocompletion <jpoiret>i don't think we support anything less than i686 <jpoiret>you could try to add the arch to the list of platforms and see if it works, but you'll have to build everything yourself <jpoiret>including a cross-compiled bootstrap <jpoiret>are you sure your CPU doesn't support i686? <yaslam>jpoiret: yes, because when I booted it on the machine it had a kernel panic that said the ISA level is lower than required, and this was with the i686 iso <yaslam>jpoiret: thanks, I will take your advice. <jpoiret>if your CPU doesn't support i686 it might also just be too under-powered for Guix <nckhexen>I'm wondering how much RAM this bad baby has. <yaslam>i don't know, probably a very small amount lol <Guest41>Is it possible to compile something from source in guix <jpoiret>yes, any guix package is built from source, the only reason you often don't build it yourself is because you can also download binary substitutes from the CI <jpoiret>you can do `guix build --no-substitutes` to build without substitutes <Guest41>jpoiret can i compile a program without building a package? <jpoiret>uhm, yes, it might help if you explained what you're trying to achieve first though <jpoiret>if you just want to `gcc myprog.c` or something similar you can just install `gcc-toolchain` for that <jpoiret>no need to go through Guix (although it can help you setting up everything) <Guest41>jpoiret I don't have something in particular in mind. just if i have a program on github and i want to compile and run it on guix, I can do that without buildng a package. <jpoiret>yes, just like in any other Linux distribution <jpoiret>we ship compilers for lots of languages <jpoiret>but if it's a program you mainly want to use instead of work on, then you'll probably want to package it down the line :) <Guest41>jpoiret so what is the advantage of building a package for it? <jpoiret>it's managed by Guix, meaning that if dependencies are upgraded it's rebuilt with them, and you can use all of the nice Guix features with it <Guest41>jpoiret sounds good, then i am totally free, I can install anything I want , if I have the sourcecode for it . awesome <jpoiret>note that this is not specific to Guix though, like I mentioned above this is applicable to almost any Linux distribution. You might want to look into the specific features of Guix first <Guest41>jpoiret I could just compile emacs 29.2 and then use i, though there is no package for it in guix atm <jpoiret>ah yes. Although you could just as well patch it to 29.2 in Guix without going through the manual build, that will probably be faster <rekado>Guest41: you can also use package transformations to leverage existing package definitions with new source code. <mrh57>Does anyone know when zig 0.11 will be available? I wanted to package rivercarro but the latest version (3.0.0) requires zig 0.11, and I couldn't get the older version (0.2.1) to build with zig 0.10. I'd try to build zig 0.11 myself but zig seems rather unwieldy (I've never packaged any zig for guix) <sneek>mrh57, jpoiret says: the .eln file hash problem is due to grafts, grafts change the final output name, but they can't also update the file hashes... we'd need to modify emacs' behavior for this to work <jpoiret>mrh57: zig 0.11 features a new bootstrapping mechanism that relies on a pre-built WASM binary <radio>Ok, now I can say for sure, it's happening to multiple programs <radio>+radio at buer in ~ > file (which pavucontrol) <radio>/home/radio/.guix-home/profile/bin/pavucontrol: symbolic link to /gnu/store/7cw0gnn74zv3nr3qd2ilb1pyzaf9cnap-pavucontrol-5.0/bin/pavucontrol <radio>+radio at buer in ~ > file /gnu/store/7cw0gnn74zv3nr3qd2ilb1pyzaf9cnap-pavucontrol-5.0/bin/pavucontrol <radio>/gnu/store/7cw0gnn74zv3nr3qd2ilb1pyzaf9cnap-pavucontrol-5.0/bin/pavucontrol: empty <radio>I want to submit more information to a bug report, but didn't receive any number for my issue, how can I do so? <radio>I sent the email some hours ago <radio>Rovanion: no :/ already looked for it in there <radio>+radio at buer in ~ > for file in ~/.guix-home/profile/bin/* <radio>/home/radio/.guix-home/profile/bin/mpv: empty <radio>/home/radio/.guix-home/profile/bin/pamixer: empty <radio>/home/radio/.guix-home/profile/bin/pavucontrol: empty <radio>/home/radio/.guix-home/profile/bin/pinentry: empty <radio>/home/radio/.guix-home/profile/bin/pinentry-gtk-2: empty <radio>/home/radio/.guix-home/profile/bin/redshift: empty <radio>/home/radio/.guix-home/profile/bin/yt-dlp: empty <radio>guix is placing multiple empty binaries on my store <Rovanion>radio: You want to use a pastebin for sharing multpile lines. <nckhexen>There's no way to follow up on a bug that hasn't been created, I'm afraid. <graywolf>nckhexen: b71c7c472a0a56c6935b4fa2a2e9c78d8ac8ea27 the solution is to compile with libbsd <graywolf>adding pkg-config to native-inputs, libbsd to inputs and --with-libbsd to configure-flags makes opensmtd 7.4.0p0 work just fine <nckhexen>‘guix build: warning: /home/nckx/guix/gnu/packages/admin.scm: file is empty’ sigh. <gabber>radio: sometimes mail (like bug reports or postings to the mailing lists) have to be approved before they enter the system <gabber>ah, so the email has not yet left the the MUA i guess (: <nckhexen>radio: Do you have access to server logs? <nckhexen>Or anything that talked to eggs.gnu.org? <nckhexen>You wouldn't be the first to report a 250 that didn't seem to arrive, although in this case it's still very likely that it's ‘just’ an internal delay. <nckhexen>As annoying as it is, I'd wait another day and then re-send the original mail + your follow-up if the first one never arrived. <nckhexen>In which case I'll ask the FSF sysadmins to take a look. <rekado>it took me much too long to realize that having a file called “guix.scm” in a directory that’s on the load path is a very bad idea. <rekado>for example: it breaks open-inferior <euouae>I'm trying to install guix in the manual method with bare-bones.cfg and I'm getting an error that //boot/efi does not look like an EFI directory <gabber>euouae: so you have already installed Guix System and are attempting a reconfigure? <gabber>would you mind sharing your configuration and the output of the $(guix system reconfigure config.scm) attempt through a paste bin? <gabber>do we want remarks on the <bootloader> record in the source file itself or rather in the reference manual? <euouae>Do you need the hash? because I've snaped a pic of the message <gabber>are you not on that machine right now? <gabber>easiest (for you) were if you had some sort of serial (or other) connection which printed all that to a console or terminal and you could just copy/paste that <euouae>I only have one laptop with 2 hard drives and I'm on debian right now <euouae>I could boot on guix but I'm a bit lazy, unless you absolutely need it I'd rather type out the last part <gabber>whatever is easiest *for you* (: <euouae>nckhexen: well this is right after a reboot. wouldn't /boot/efi be mounted? <euouae>I did a gdisk, new GPT table, 2 partitions, first of size 512M and fs label EF00, of fs fat23, second a linux filesystem ext4 <euouae>nckhexen: do I need to mount /boot/efi before guix reconfigure? <nckhexen>Ah, FAT23 ☺ That's all great, but if you don't tell Guix how & where to mount it, it won't. <nckhexen>Yes, it's the Guix equilavent to /etc/fstab. <euouae>I think bare-bones.cfg has a few pitfalls <euouae>last time I tried it I forgot to install an ntp server and nss certificates <nckhexen>It also does not do EFI, as the left-over comment notes. <nckhexen>You changed it to -efi-, but that also implies adding an ESP mount point etc. <euouae>there I thought I just had to change grub-bootloader to grub-efi-bootloader <euouae>yeah I think the manual didn't elaborate on that <euouae>the early steps of a boot are quite cryptic. it's hard to find information online <nckhexen>I don't think bare-bones.tmpl is a good starting point for a generic system. It's not meant to be. <euouae>nckhexen: well it's not a generic system -- I'm trying to learn :) <gabber>i wanna test an operating-system definition, do $(guix system vm config.scm) get an error that info-dir.drv build failed and the logs are... gzipped but still empty :( <nckhexen>euouae: True, it assumes you know that already. A short addition (or just beginning the 2nd paragraph after the mkfs -F32 command differently, so it's less implicit) would be a welcome patch. <attila_lendvai>gabber, try without $(), it usually prints a bit more to the stdout <nckhexen>Er, why is everyone getting empty files today. I hope it's just a spooky halloween coincidence. <radio>nckhexen: are you getting it too? <nckhexen>If I may ask: please keep it as short as possible, the more text we add the more people seem to skip. <euouae>nckhexen: I have a lot of opinions on that kind of thing (in general not just guix) <gabber>attila_lendvai: i did it without the $() - i only use these marks to imply bash commands <euouae>I think documents should be multi-presenting, appearing different based on experience level and goal sought. <euouae>so that they're always as consise as they should be... with an easy switch between "give me more detailed info" and "skip the easy stuff" <gabber>the only message indicating failure before the error message is: "builder for `/gnu/store/95s5mcx88y443q72bja745c29a94f7b8-info-dir.drv' failed with exit code 1" <gabber>i'm on a time-machine commit from a couple of weeks (or months?) ago... and naitively compiling for aarch64 (while on a x86_64 host) <gabber>ACTION thinks that maybe today might just not be the right day to do these things <nckhexen>/proc/sys/kernel/unprivileged_userns_clone ? <gabber>ah yeah, i overread "Currently, the script must be run as root in order to support more than a single user and group." <mrh57>for the zig build system, is there a way to ignore the runpath check (as it is ignored in the building of zig itself via cmake)? <nckhexen>If you mean the phase inherited from the gnu-build-system: (modify-phases %standard-phases (delete 'validate-runpath) …). <nckhexen>Obviously, a comment pre-empting the inevitable ‘wait, what, why’ is probably appropriate. <nckhexen>If serious: if the runpath is ‘invalid’, can we, ideally, make it not invalid instead? <nckhexen>If for some reason Zig is unable to produce the good runpaths, it seems the original author of the zig-b-s disagreed. <nckhexen>Oof, I just pushed a patch like 5 minutes ago. <nckhexen>ACTION has to go shopping now, tomorrow being a holiday. <jackhill_>Sometimes when substituing from another host running `guix publish` on my local network, the larger guix operation (e.g. reconfigure) dies with a message like "guix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function." <jackhill_>retrying allows it to make more progress (although I haven't been paying enough attention to know if it's getting the problematic item from the same substitture server. <mrh57>nckhexen: thanks! the biggest trouble I've had with packaging things is knowing which build options go where (and also gexps...) <podiki>euouae: just checking in and saw some messages that all is fixed? was an issue of not mounting the /boot/efi partition? (glad it was something easy, we shoulda seen it last night!) <euouae>podiki: yeah that's what it was :) I did not have /boot/efi listed under filesystems in config.scm <podiki>i should have looked at the config you started with, very obvious in hindsight <euouae>I think I will submit a small patch for this, a quick comment in the info manual about including /boot/efi <podiki>a better error will help, though "not an efi partition" is technically true when nothing ism ounted there <podiki>right, good for someone starting a config from scratch for instance <euouae>That's the grub-install error I believe <podiki>yeah, it is not wrong, but not specifically helpful either. i guess we should have looked to see what was at that mount point <euouae>one of the most cryptic parts of Linux for me is the boot process <podiki>grub does no one favors either usually <graywolf>Hm, I think c0895371c5759c7d9edb330774e90f192cc4cf2c is wrong. <podiki>also pretty fascinating, the various bits in an early system and booting, just usually finding out about it through some catastrophic error :) <apteryx>does Guix System ensure something like efi=runtime for its kernel command lines? <apteryx>when using UEFI; real question: can /sys/firmware/efi/efivars be empty for $reasons when using Guix System? <euouae>the manual says if it's not empty you're on UEFI for what it's worth <euouae>apteryx: and also, since it's under /sys, I think that's the kernel/modules taking care of it, so I can't think of any $reasons myself <apteryx>vivien: would you like to join the GNOME team? <nckhexen>apteryx: Is there a reason you're asking? <nckhexen>graywolf: As a (mostly) udev neophyte, that diff + that commit message seem to contradict each other. Is that what you mean? <graywolf>Maybe, the systemdrun there is weird, but not an udev expert. But the syntax is wrong and spams the log <the_tubular>What would be the best way to push and keep up to date an /etc/host file to multiple endpoints using guix ? <graywolf>I am in process of trying to figure out emacs-debbugs in order to reopen 65177 <nckhexen>Apart from that, nothing in the patch even mentions EFI partitions at all. <nckhexen>graywolf: You can reopen it via e-mail but I'll let you struggle & grow. <graywolf>> Did not alter fixed versions and reopened. <graywolf>Did I do that? Did it happen on its own? <peterpolidoro>I am trying to create a package and the python files are in a GitHub releases zip file, not necessarily in the repository itself. the python files might be generated from the files in the repository, but I do not documentation or code on how that is done <peterpolidoro>can I use the copy-build-system with a releases zip file instead of the files from the github repository? <nckhexen>the_tubular: So I'm subscribed to the bcachefs list, but wasn't completely certain that I interpreted that message correctly. I guess I did. Yay. <yaslam>peterpolidoro: yes, you can, there is an "unpack" phase in copy-build-system, make sure to add the "unzip" package to your inputs though <peterpolidoro>yaslam thanks. does that still count as proper source code even though it might be generated from other source files in the repository? <nckhexen>So… you're just installing Python sources? <peterpolidoro>there are .fbp files in the repository and in the release zip there are .py files. <nckhexen>There are a few packages in Guix that bend the rules but no, generated Python files are not source… <peterpolidoro>so I should figure out how to convert the .fbp files when building the package? <nckhexen>(They didn't click the ‘export as Python’ menu item or whatever? I'd never heard of wxFormBuilder :) <peterpolidoro>I have never heard of .fbp files, I guess I have some researching to do thanks <nckhexen>I gather it's a visual programming tool, so the .fbp files are source, even though they might not have been written by a human. <peterpolidoro>so does that seem possible to convert within a guix package? maybe if I can find a command line tool? <nckhexen>‘To change generate code to Python from the default C++, just click on the project at the top of your project tree on the left. Then under object properties on the right, you will be able to choose the languages you want to output to under the 'code_generation' setting and the file name can be changed in the 'file' setting. It will add a .py extension by default.’ <peterpolidoro>looks like I will need to do this on a day when I have more time on my hands, thanks! <nckhexen>That said, this could end in a ‘(build-system copy-build-system) ;XXX TODO package wxformbuilder’ comment if I'm honest. <nckhexen>Do that, submit it as a patch, see what people say, someone might even help (one can dream). <graywolf>Can anyone close any bug report? Or only author and a designated people? <graywolf>Is it ok to close bug reports that should be closed but are not? Or is this type of gardening better left for the committers? <vagrantc>if you're sure it is resolved, go ahead and resolve it ... ideally linking to whatever proof that it is done (e.g. a guix commit) or at least describing why it is done <vagrantc>sometimes things are left open because part of the issue is unresolved ... possibly then better to retitle the issue to make it more clear what is left <vagrantc>but a little housecleaning of the bugs is surely appreciated! <vagrantc>worst case, an issue has to be reopened later, which is not hard to do <graywolf>Cool, will keep the stated guidelines in mind. Thx. <vagrantc>mind you, they are not formal guidelines ... just things i made up :) <vagrantc>ok, i can go back to lurking for another month or two now. :) <nckhexen>‘not formal guidelines ... just things i made up’ in which vagrantc accurately describes most formal guidelines. <podiki>going on a bug closing spree is nice (for ones actually fixed of course) <podiki>feels as good as checking off a todo list with less of that pesky work <podiki>old patches to update things that were now even further updated is low hanging fruit too <vivien>cbaines_, I pushed a V3 so the problem should be fixed. <cbaines_>vivien, OK, out of interest, how did you send the series that wasn't ordered correctly? <vivien>I sent it with Evolution, the patches are always out of order when they leave my mail server but it looks like Patchwork or QA now consistently order them by date. You can see on the issue page, they are in a random order, but the QA page lists them in order. I reset the author dates for V3 so they should come in the correct order. <vivien>My mail server is on a slow machine, it usually needs a few seconds to process each mail in the queue. <cbaines>vivien, OK, I know you had some code for doing the ordering in QA and I'm not against using that since it seems that the non "git send-email" case maybe isn't supported as well as it could be <vivien>At first I thought it was because of Evolution, because Evolution would send the patches in chronological order of the Date field (i.e., author date), but looking at the issue for V3, they should then be in the correct order (cover letter coming last). This is not the case, so Evolution is not the only one to blame! <apteryx>1 hash mismatch for store item '/gnu/store/dfv5mppsr8z76pj37km0p11aqw721qia-linux-libre-deblob-check-6.1.60-gnu <podiki>yes, that's the issue; personally haven't looked at the provided patches but seems the right idea (hash updates) <jackhill>cbaines: congrats on the blog post (and the grant)!! A typo: "switching between the C++ implementation and Guile implementation which any issues" → "without any issues" <valconius>Question on copy-build-system: if all I need is to copy an sh file to bin, how would I do that. <rekado>when I have an existing profile directory (/gnu/store/…-profile) can I make that the next/current generation of an existing profile without fiddling with symlinks directly? <valconius>And I mean: how do I add an arbitrary single child to the gnu store, I guess. How do I specify a single-file source as a local sh file instead of a tarball over the Internet? <nckhexen>(Or even plain-file, to answer the more general case in the second message.) <nckhexen>But combining this with copy-build-system is weird. <GNUtoo>hi, I've a strange error while trying to cross compile aarch64 images <GNUtoo>I use an operating-system file with only grub-bootloader that isn't even installer (installer #~(const #t)) and that has an ext4 filesystem at / and a hostname, <GNUtoo>And for some reasons I can't find a revision of Guix that works <GNUtoo>What fails is gawk-mesboot, however that is not exported. Right now it fails with 'checking host system type... Invalid configuration `aarch64-linux-gnu': machine `aarch64' not recognized', but before it also failed (I don't remember the reasons). It also fails with guix time-machine --commit=v1.3.0 and v1.4.0, which is strange <GNUtoo>Is there a way I can use the public data on the CI infrastructure to narrow down the issue and get at least 1 commit that work to narrow down the git bisect? <GNUtoo>ACTION has tried to track that down for quite some time (time here and there during several weeks) <GNUtoo>Ahh I didn't see that you can't download anymore the pinebook pro image, though the CI currently says "Still succeeding" <GNUtoo>when trying to download it I have {"error": "could not find the requested build product."} <mekeor>sneek: did you tell me what jpoiret told you to tell me? <sneek>me, mekeor says: what jpoiret told you to tell me? <mekeor>jpoiret: which graft changes the output name of .el-files from emacs-related packages? <mrh57>do people prefer to declare their main user packages in explicitly in guix home, or use guix home just for configuration and use manifests? <GNUtoo>There are advantages and disadvantages for both approaches <GNUtoo>Guix home can be used on many different computers for instance <GNUtoo>But personally I prefer guix system as packages also work with 'sudo su' etc <mrh57>mm yeah I hadn't thought about using guix home to deploy to multiple computers <GNUtoo>As for manifests I tend to only use them to work on official projects and add the manifest in the git of the project upstream. <Kolev>Is it better to call it manifest.scm or guix.scm? <GNUtoo>This way I can share the configuration with other people working on the same project. <GNUtoo>because guix.scm is something else <GNUtoo>I use guix.scm to run automatic tests <GNUtoo>and manifest.scm to provide a shell in which users (like me) can test stuff <GNUtoo>Some guix.scm are also present in other official projects, usually they are somewhat culturally related to guile or guix <Kolev>GNUtoo, but for reproducing the environment in which a project is developed: manifest.scm. <GNUtoo>With manifest.scm you can run something like that: 'guix shell --pure --container -f scripts/manifest.scm' <GNUtoo>So you get a shell and can run './autoge.sh && ./configure && make' and work on the code locally <GNUtoo>so here you edit the source file and build locally like you would on any GNU/Linux distribution <GNUtoo>The guix.scm however is typically used to build packages <Kolev>The documentation on Guix Shell said guix.scm and manifest.scm were the same, so I always wondered. <GNUtoo>So you could modify source files before building the package but it's not very convenient as you can't interrupt the package build right after ./configure <GNUtoo>and the build times are long as it copies everything in a separate location (in /tmp) for building <Kolev>GNUtoo, so Guix System can do Replicant development? Cool. <GNUtoo>so it's better for automatic testing (like building 3 versions of your package with different libraries or compilers) <GNUtoo>Yes and no, it's only limited to some specific libraries <Kolev>So for my simple use cases, manifest.scm is proper. <mekeor>guix.scm contains a package declaration; manifest.scm is a list of packages. i.e. a manifest somewhat corresponds to the package-inputs of the package declared by a guix.scm, i guess? <GNUtoo>And here we used Guix to do some semi-automatic tests with different libc and compilers to catch bugs before they are commited. <Kolev>Oh, guix.scm is the Guix package for the software in the git repo? <GNUtoo>Kolev: not really, basically we just want to build that library with different compilers to try to catch bugs early <GNUtoo>It's more for (semi-)automatic testing <GNUtoo>The packages run 'make check' for instance, and our library broke with compilers changes for instance. <GNUtoo>There was a presentation about the guix.scm in some Guix conference, that's where I learned about it. <Kolev>So how do you release a Guix package for a piece of software? Make another Git repo that's just Guix packages? <GNUtoo>not really, it's not packaged yet anywhere beside in Replicant because it still somewhat relies on non-upstream kernels <GNUtoo>I'd also like the stabilize the API / ABI and do some more code cleanups before having packages everywhere <Kolev>But if the project wanted to release a Guix package quickly and independently of the Guix repo... <GNUtoo>and the fact that it use package is because it's easier to run automatic tests this way <GNUtoo>you build stuff in a somewhat standard way, can control the dependencies and run or not some tests in the test package building phase <GNUtoo>doing that without guix build might be possible but it's probably way harder <GNUtoo>I've tried to do that to do some toolchain testing but at the end I ended up using guix build again <Kolev>As I said before, I have no need for tests right now, and manifest.scm would work fine for me as far as development goes, but I'd like to know the proper way for a project to release a Guix package for its software without having to submit a package to Guix project. <GNUtoo>I'm not sure about that, if you add the packages in some lisp file you can do something like 'guix package -i -f ./my-package.scm' <GNUtoo>but then the package is not usable in guix system <GNUtoo>Another way would be to create a channel, this way it's available everywhere. <GNUtoo>And in your case I've no idea if it's a good idea or not to name the file guix.scm as there are usually packages inside but the presentation presenting this idea tended to show it was for testing <Kolev>GNUtoo, so the proper way is to create a Guix channel. <GNUtoo>If the file is also a module then you could (with -L . ) use it in guix system but that forces users to use '-L .' <GNUtoo>yes, it's probably easiest for users <GNUtoo>+ with the channel users can get updates and so on <GNUtoo>So once configured it's transparent I think (though note that I didn't test channels yet) <Kolev>But since a channel is just a Git repo, we'd have /example-project for the actual source code and /example-project-guix for the Guix channel. Seems messy. Unless there is a way to put the Guix channel into the source code of the project. <Kolev>Let me see how rde handles it. <Kolev>Trying to edit the .desktop file to launch Tor Browser from GNOME. <Kolev>It says my sys. arch. is wrong. <GNUtoo>ACTION ended up bugreporting with my aarch64 system cross compilation issues, strangely I can't build pine64 images either, and they can't be downloaded but CI says it's fine <Kolev>How do I get specification->package to operate on more than one arg.? <nckhexen>Kolev: You don't, but like any single-argument procedure it can be mapped. <Kolev>nckhexen, yes, map! Thank you! <Kolev>(map specification->package "tmux" "screen" "vim" "emacs") <mrh57>when defining a package, is there a way to pin the versions of the programs used by the build system? <Kolev>Does bsd-games not include fortune? <devmsv_web>Hello everyone, how can I execute a gexp in the repl or debug it? I have an mcron job that is failing and I need to debug it <vivien>apteryx, the application test for Calls fails with: (process:2130): callaudiod-pulse-CRITICAL **: 07:10:06.171: No suitable card found, stopping here... <vivien>Is there something to initialize pulseaudio in a build container? <rekado>devmsv_web: it needs to be built because it may contain references to packages that can only be known after building. <rekado>what does the generated mcron file look like? <voroskoi>how can use herd in a verbose mode or something? fails to start my service, I would like to figure out what went wrong <zamfofex>Hmm, I wish ‘C*_INCLUDE_PATH’ weren’t shared between the “compiler for the target” and the “compiler for the build machine”. I’m currently running into an issue on my “WebAssembly target” thingie where Clang is picking up headers meant for GCC and glibc and then failing. I tried taking out GCC and glibc from the build, but ‘gnu-build-system’ needs it for ‘CC_FOR_BUILD’. <rekado>zamfofex: we have CROSS variables for distinguishing settings between target and host. <zamfofex>rekado: There does not appear to be such ‘CROSS’ variables in the cross‐build environment. <jbnote>Hi there, i'm using guix in a cluster setup approximately as described on the blog post from 2017, except the master and nodes are running GuixSD. I'd like to be able to run guix-daemon on the nodes, too, with a /gnu/store and /var/guix shared over NFS, in order to take advantage of the compute power (and native architecture) of the nodes (with a local scratch for tmpdir). Is such a scenario possible? I'm a bit wary of trying and <jbnote>corrupting the store with concurrent access over NFS :) If not, do you have a way to share the /gnu/store storage and distribute the CPU tasks? I've looked at cuirass-worker too, but I feel it would use a locally-running guix-daemon anyways. <rekado>jbnote: I don’t think you can easily do that. <rekado>jbnote: a weird option could be to set up containers on all of the cluster nodes, have them run their own daemon and their own tiny store, and set them up as offloading machines <rekado>then the main guix-daemon can ask the other nodes to build packages and return the results to the single shared NFS store <rekado>by using guix in containers you bypass the problem of coordinating simultaneous writes to /gnu/store (which are not supported) <rekado>the containers would get their substitutes from the main server, so whatever has ended up on the main node will be available to the builders <rekado>it’s just a little wasteful as you can’t just take existing files from the shared /gnu/store over NFS. The containers on the build nodes would instead get their build prerequisites from the substitute cache on the main node. <jbnote>rekado: yes, this is a good idea. the store duplication would be minimal. I'm already spawning qemu VMs on some of the nodes, so the complexity is manageable. What kind of container would you use? <jbnote>rekado: thanks, I will look into it. <rekado>and I’d probably add a bridge interface with veth/ceth connecting the container system with the host network <zamfofex>rekado: Regarding the ‘CROSS’ variables you mentioned: Have I misunderstood, or otherwise am I misunderstanding something? <rekado>jbnote: or do without the bridge and arrange for the system containers to get their own IPs some other way <zamfofex>(I now realised I just said “am I misunderstanding” in two different ways.) <jbnote>rekado: yes, i'm already using this with the qemu VMs -- adding a macveth interface with the recent commits in static-networking is a breeze. You don't even need a real bridge anymore. <rekado>jbnote: if you make this work I’d be very happy to read your notes <rekado>(and incorporate them in the cookbook) <rekado>zamfofex: maybe I’m misunderstanding something here, but we’re patching our GCCs to respect CROSS_{C,CPLUS,OBJC,OBJCPLUS}_INCLUDE_PATH, and CROSS_LIBRARY_PATH. <zamfofex>rekado: Ah. Well, the two issues I’m running into is that I don’t see those variables in the build environment at all (even if GCC respects it) and also that I’m using Clang on the build environment (because GCC does not have a WebAssembly target yet). <devmsv_web>Finally saw my stupidity I was trying to get a gid from a list of users instead of the vector group <devmsv_web>jbnote I will also be interested in what you achieve as I am building a slurm HPC with Guix System myself. Will you be at Montpellier workshop? <jbnote>devmsv_web: probably not, unfortunately. I'll ask my employer, though. <adamnr>Looks like chat log archive is not updating <rekado>the current logs are actually still in the Oct logs 