IRC channel logs
2023-11-23.log
back to list of logs
<Guest14>does qemu-binfmt-service-type only support 1 cpu? <Guest14>ah nvm, at the moment i wrote it, it now uses all cores <jfauhn>Anyone here have any experience writing packages for guix? <mange>I would assume so. Is there a specific question that you're looking for help with? <oriansj>and precise questions can be answered by a larger population than just the experts <jfauhn>I am just looking into contributing to guix and want to get to know the community right now <jfauhn>I see that platform-tools is increadably out of date <ieure>jfauhn, Updating packages already in Guix is very straightforward, that'd be a good place to start. <ieure>Those should be enough to get you started! <jfauhn>Thank you! I really appreciate that. I did not know about guix refresh. <oriansj>jfauhn: guix is too big for anyone to know everything about everything. <oriansj>but with the advantage that all of the people who do know the bits are still alive <Kolev>oriansj, I've asked rms about stuff from the 60s and he can't recall. <oriansj>side effect of a life worth remembering; too many novel experiences to remember them all <Kolev>oriansj, like, "where was the Control key on most of your terminals when you were using EMACS?" <oriansj>seems like the sort of question which would be better asked as what terminals did you use and then just looking <oriansj>but on a long enough time line, people start forgetting even the big details. Like what was your first computer (as those memories will blend together) <Kolev>My first computer was some sort of Vaio laptop in 2001. <oriansj>IRC is where you can find people only past the 3rd year bit discussing things with those who are past the 6th year bit in life on equal terms. <Kolev>oriansj, a VIC-20 is basically a BASIC machine, right? <oriansj>well the only baked in language is BASIC but you need to use assembly if you want to create anything serious. <oriansj>but it isn't that hard to create your own assembler if you have good hardware documentation <Kolev>oriansj, BASIC should be enough. <oriansj>as one who wrote a C compiler in assembler; I never bothered to learn BASIC as it left too much on the table and there was no way to work around a bad RAM chip in it. <oriansj>the line at the time was using BASIC was like masterbating with a cheese grater; just don't. <oriansj>but yeah, FORTH was a popular language too bootstrap. FOCAL was available if you were willing to replace the ROM <oriansj>only later after upgrading to a PC did turbo pascal become an option <Kolev>I just realized, Guix can mean both "GNU Nix" and "Guile Unix." <jfauhn>I think I am pretty slow at getting the hang of using guix. One of my issue is that you can't really just follow a tutorial online without really having to dig into how guix varies. <jfauhn>Kolev, Yes most tutorials online is on a debian based distro and I have trouble grasping how to get the stuff working in guix. <Kolev>jfauhn, oh, I see. Yeah, Guix is not as well-documented as Debian et al. <oriansj>jfauhn: well guix tends to be what you desire but if you don't know what you want; it can be frustrating. <oriansj>did you install alsa-utils and do: sudo alsamixer ? <Kolev>oriansj, I'm on a Chromebook. This configuration is necessary for audio to work. I guess I can try that. <oriansj>and if you installed pulse audio, then you would need to do something else as it overrides alsa <jfauhn>Hey I have also noticed that if I download a binary off the internet guix will not let me run it. What is up with that? <oriansj>and looking at the repo you have posted, you would be just creating an alsa configuration file (~/.asoundrc) <oriansj>jfauhn: guix lets you run anything you want. It isn't guix's fault if your downloaded binary doesn't know how to properly link and load <ieure>oriansj, ALSA is in the Linux kernel, PulseAudio is userspace. It does not, and cannot, "override ALSA." <ieure>It might change some ALSA settings or something. Wouldn't call that "overriding." <jfauhn>oriansj, oh I thought it was a security thing. It was fastboot from google's platform tools. <oriansj>ieure: fair enough perspective. But audio stopping to work just because a program spawns pulseaudio and nukes your audio settings does feel that way. <oriansj>jfauhn: yeah that is a dynamically linked file. You would need to do an ad-hoc environment if you wanted to run that binary or you would need to patch the linkages in the file itself or just do a local build <efraim>apropos of nothing, I haven't been able to get bash-minimal to build for x86_64-w64-mingw32 <efraim>rav1e uses cross to cross-build packages, makes it really hard to get cross-compiling working <lilyp>Can we have exact name queries on CI please? It hurts searching for "Emacs" or "Minetest" and getting a bunch of related, but not searched-for matches <lilyp>I got it to work with name-version <oscarvarto>Hi! Is it possible to install "shell frameworks" like starship or oh-my-zsh to enhance the shell experience on guix? I would like to use fish and take advantage of autocompletion stuff that get's installed commonly <Elouin>Hi, is there a service with which i can define docker containers i want to have running on my system? <civodul>Elouin: hi! there’s ‘oci-container-service-type’, which landed literally minutes ago <civodul>not sure if that’s exactly what you want <Elouin>civodul: Yes, that looks exactly like what i was looking for. :) <ekaitz>what are the numbers? times the package was built? or the dependant packages? <gabber`>my $(guix system image foo.scm --system=aarch64-linux) seems to need to build qemu-minimal for aarch64 -- which eventually halts. if i check $(guix weather qemu-minimal@8.1.1 --system=aarch64-linux) i get 100% coverage (at least on one substitute server). building qemu-minimal@8.1.1 halts (but won't return) even after two days (while there's a good 1000 zombies spawned). is this intended behaviour that my build won't use the <gabber`>substitue? (how) can i resolve the issue? <ekaitz>gabber`: that certainly shouldn'thappen <hako>ekaitz: Yes, dependent packages, can be told from the heading "Package changes" as well. <ekaitz>hako: but then if I click in comparison, the ones that appear don't make a lot of sense <gabber`>well, i am on a Debian (based?) system, so i might have missed something in my setup? or maybe it's a bug that we missed since we're usually working on pure Guix Systems? <ekaitz>all the packages build but qemu itself? and how do the rest of them build then? <gabber`>ekaitz: i don't get to build the other packages since qemu won't finish building <ekaitz>gabber`: i was talking with hako about that sorry, that was another issue I have with qemu <ekaitz>so gabber` let's investigate your issue <ekaitz>you are trying to use qemu-minimal in arm and it doesn't build... it just hangs <ekaitz>in what kind of computer are you building it? <gabber`>not quite. i do a $(guix system image --system=aarch64-linux) while on a Debian x86_64 system <gabber`>it works (as expected, by pulling substitutes) for package `hello' <gabber`>not sure what i would have to configure (and where) but i guess so, yes <ekaitz>in a guix system you have to add a couple of config lines <gabber`>it also works for a heavy package like `gcc-toolchain' <gabber`>there's no need in debian. installing qemu-binfmt automagically adds the corresponding service to systemd (and also starts it) <ekaitz>btw i just built the non-minimal qemu <gabber`>the non-minimal qemu@8.1.1 gets substituted as well, it's just qemu-minimal@8.1.1 that interestingly needs building -- even though $(guix weather) shows a present substitute on bordeaux.g.g.o <ekaitz>cbaines: and how can the main package fail to build and all the dependents build? <ekaitz>cbaines: if you click compare *x86_64), that's what it shows right? <ekaitz>gabber`: you can try build qemu@8.1.1 and see if it hangs too? <gabber`>qemu@8.1.1 builds (aka gets substituted) without an issue <ekaitz>gabber`: yeah but what it might be interesting is if your computer is actually capable of building it or not <ekaitz>gabber`: what is happening with the minimal is that there are not substitutes (for whatever reason) and you can't build it yourself <ekaitz>gabber`: probably you can't build the other either but it gets substituted so you don't have to and we don't see the larger problem <gabber`>i'm ok with not being able to build qemu on that machine (it's our unfortunately not-beefy-at-all CI server) <gabber`>but i do need that machine to build an image for aarch64 :( <ekaitz>gabber`: i understand but guix substitutes are not always available... so sometimes builds will trigger <cbaines>ekaitz, looks like the comparison here is affected by #67250, so some of the differences the data service is highlighting are due to fixed output derivations changing <gabber`>is it possible to send relevant builds from my local store to that machine? <cbaines>the issue doesn't quite describe that, but it's the same underlying cause <cbaines>ekaitz, I think the test failures showing up for qemu/qemu-minimal are still relevant though <ekaitz>cbaines: can we re-run this or something to see the actual results? <cbaines>ekaitz, we can, although I don't think that'll fix the failed builds <cbaines>ekaitz, it's possible those builds ran on a machine using btrfs, which could be related to the test failures <ekaitz>gabber`: hmmm im not sure about that <ekaitz>cbaines: i just built qemu and qemu-minimal with no issues and all the tests passing so there's not a lot more i can do from here i think <cbaines>ekaitz, did that build happen on a btrfs filesystem? <cbaines>ekaitz, I've checked one of the failed builds, and it happened on btrfs <ekaitz>and how can i test this on my own? <cbaines>ideally QA would help, but it's limping along with 2 and a bit x86 build machines <cbaines>I'll try submitting a build to run on a machine with an ext4 filesystem though <ekaitz>the error is very specific though, maybe i can find some info about it <ekaitz>cbaines: i already found some info online about disabling cow for qemu images <cbaines>the builds on ext4 are now happening as well, so hopefully they'll succeed or fail soon <cbaines>the future on QA still seems quite uncertain, but it would be cool in the future if we could automatically test and diagnose issues like this <cbaines>the relevant builds should stand out as they just have filesystem: ext4 as the tags <ekaitz>cbaines: stupid question! where does it leave the finished builds? <cbaines>ekaitz, are you asking what happens to the outputs (the /gnu/store/... bits)? <ekaitz>it's way more stupid than that, in the /activity page you sent me one of the builds finished and now I don't know where to see the status <cbaines>one of them has failed, but it looks to be an issue with the build coordinator :/ <cbaines>I've got a bug in the build coordinator to fix though :( <lechner>Hi, does HEAD in Git currently fail several tests? I see gexp, syscalls and guix pack failing so far <civodul>i see where the tests/gexp.scm failure comes from, will look into it later <ekaitz>cbaines: qemu failed again in bordeaux... but it works in my machine :) <cbaines>ekaitz, same test failure on bordeaux? <ekaitz>yeah its the one you sent me before <cbaines>ekaitz, that build definately happened on a machine without btrfs <cbaines>that has 5 failures, whereas the other build had just a single failure "753/824 qemu:block / io-qcow2-copy-before-write" <ekaitz>and that specific failure is repeated in both <ekaitz>gotta go now but i'll research this a little bit further <ekaitz>the version of qemu we currently have has an issue for riscv <cbaines>I think the QEMU test suite has been difficult for a while, so this probably isn't something specific to your change <cbaines>but it would be nice to have the package build more relabily <ekaitz>in my setup builds and passes every single time <cbaines>that sounds great, I want your computer :D <ekaitz>it only happens with this package, most of the rest always explode, but it's probably my fault :D <ekaitz>so now i don't know what to do with this <cbaines>I don't see the failing builds as a blocker given you say it can be built <ekaitz>we'll see then, thank you cbaines for your help <cbaines>(you might need to refresh without caching) <lechner>Hi, why does this output from 'make check' count four "FAIL" statuses but shows only three failing tests, please? Is the count off? https://bpa.st/ACVA <yewscion>Hey Guix! Is there a workaround currently for the emacs packages that won't build with 29.1? I'm trying to revert to 28.2, but I think that's more complicated than (with-version . "emacs=28.2") for some reason, because packages still seem to be compiling with 29.1. <civodul>yewscion: hi! i don’t know of any solution <civodul>i would personally rather help fix packages that won’t work with Emacs 29 <civodul>it’s already been around for some time… <lechner>civodul / Hi, I'm still reading but the word "are" is missing in the first sentence. also, what's up with the binary patch? <yewscion>civodul: That makes sense to me, too! I was mostly wondering if there was a stopgap, more than asking for a way to make it work. It's much better to fix the underlying problems, for sure! <civodul>lechner: oh, fixing the typo, thanks for taking a look! <lechner>still reading (and playing with the new tool) <lechner>civodul / i just have a few style suggestions. please feel free to ignore based on your own preferences: Instead of "self-describing" I would write "The interface is intuitive: Just fill in ..." (that also avoids the direct "you" which is powerful but already used quite often in the text.) <lechner>civodul / i would also replace "every newcomer" with "many newcomers" <lechner>"it helps you avoid common pitfalls" instead of "lets you" <lechner>civodul / in a real pet peeve of mine, that riles the Debian folks to this day, i never use "dependency" (or "dependent packages") because they often mean the opposite thing and people often use them incorrectly. throughout Lintian, I used "prerequisite" and "consuming package" <lechner>sorry, i hope this is acceptable here <lechner>"you can change things like turn tests on and off, and add configure flags" instead of the gerunds <lechner>instead of "valid" i might occasionally use "syntactically correct" <lechner>"pretty cool, yes?" instead of "pretty cool, no?" <civodul>i think it has to be “no”, as in “Cool, isn’t it?” <lechner>but like i said it's a personal style <Kolev>Does Guix write shell scripts in Guile? <Kolev>I must learn how to do this. <lechner>civodul / "one of the *more* challenging parts" <lechner>Kolev / you will never go back. i haven't written a shell script in over a year <lechner>in a pinch /run/current-system/profile/bin/guile is your friend <lechner>civodul / would strike "basic" from SPA <lechner>civodul / instead of "provide decent search" i would write "provide helpful search-as-you-type *results* <lechner>that local browser cache thing is impressive <lechner>"while the feature set provides a great starting point, there are still a few things ..." just less convoluted <lechner>developped is often spelled with one p <lechner>i am just babbling; it makes me feel useful. no need to adopt any of these stream-of-consciousness suggestions <gabber`>Kolev: instead of a #!/bin/sh shebang you just take a guile one ;) <civodul>lechner: i’m happy with most suggestions so far :-) <lechner>civodul / i would usually not use "obviously" as it asserts a superiority over the reader <gabber`>and instead of writing "echo hello" you do `(display "hello\n")' and instead of "exec_my_prog" you'd (invoke "exec_my_prog") <gabber`>attila_lendvai: eww, non emacs-eww compatible paste :( <Kolev>attila_lendvai, just know that I had to clone your Git repo to look at that file without proprietary JavaScript. <lechner>civodul / instead of the generic "lowering the barrier to entry" i might choose "Attracting new packagers" or "Opening Guix up to a broader range of packagers" <attila_lendvai>Kolev, the -e main part is optional, but that script is written so that it can be loaded and used from a guile repl, too <lechner>civodul / for anything that exists -> for anything in language-specific repositories <gabber`>attila_lendvai: there should also be a "Raw" link somewhere (even on GitHub) <lechner>civodul / "once you have your first *.scm file, guix build *prints* hints <Kolev>attila_lendvai, thank you for considering leaving GitHub. 😀 <lechner>civodul / although i am not sure i would advertise our error reporting facilities <Kolev>attila_lendvai, a lot of modules. Which modules are necessary? <attila_lendvai>ACTION tries to stay far away from anything that m$ touches... but momentum... <Kolev>ACTION uses Microsoft fonts. <civodul>lechner: there was some effort; it doesn’t mean it’s now perfect, but rather that it’s something we care about (i do anyway) <lechner>civodul / i do too but our error reporting (or rather guile's) is widely ridiculed even though it's been getting better <lechner>compared to some other schemes, like Racket <attila_lendvai>Kolev, probably none. you will be in the guile-user module, which imports the basic stuff usually needed for scripts <lechner>civodul / the paragraph starting with "Those syntactic issues" all the way to the "reproducible, isolated builds" may be too scary for newcomers. i might strike it, or tone it down significantly <attila_lendvai>ACTION is regularly dismayed by truncated backtraces coming from guile, often turning a 20 second fix into long minutes... <lechner>civodul / other than that, the test looks great! <Kolev>attila_lendvai, so you use `system` to run commands? L129. <Kolev>lechner, L129 just says `system` and not `system*`. <lechner>attila_lendvai likes shell expansion, but i speak up every time :) <attila_lendvai>Kolev, i'm relatively new to scheme (coming from CL), so don't take the whole file as a reference for best practices. i sent it primarily for the shebang line <samplet>civodul: I agree that it should be “pretty cool, no?”. While it is used generally, it is a popular construction among francophones, who probably are thinking “n’est-ce pas?”. :) <lechner>civodul / as a final remark in my strange soliloquy i would give the new tool a more memorable name. It's fine to be descriptive, but it could be more specific. How about the "Online Packaging Assistant for Guix"? <lechner>it is possible to construct a negative with two positives <civodul>my colleague Philippe was even less inspired than me: he initially called it “Guix-UI” and i came up with “Guix-Packager” <civodul>samplet: you actually meant that this construction is rarely used, right? <lechner>this is also a negative: "yeah, right" <samplet>I meant it is used by native speakers, too, just less frequently. <civodul>ACTION ponders whether to strike the last paragraph <lechner>actually, "pretty cool, isn't it" would be better <samplet>I had to chime in because I think the way the French roots of Guix come through the writing of the blog posts is kinda charming. <lechner>i like the french. my issue is merely with negatives <civodul>reminds me of jpoiret mentioning “Nix with baguette and bérêt” <civodul>i hope the project doesn’t look too anchored in one specific territory <lechner>for anyone in the know, guix is like bourbaki! <samplet>I don’t think it comes across to folks new to Guix. (If it did, they might have an easier time pronouncing it!) <samplet>civodul: “unique in the Guix community that is” – maybe remove “that is”. <attila_lendvai>' means quoting, i.e. it'll just evaluate to a (read-only) list of values. you can use (begin ...) to run multiple expressions after one another. <samplet>“While the feature set should be enough for what the tool is intended—providing a decent starting point—,” → “While the feature set should be enough to provide a decent starting point,”. <samplet>Very nice article! Kudos to Philippe for standing up such a cool interface. <mekeor>TODO: rewrite guix-packager in guile xD <hapster>I have the guix package manager installed on a foreign distro to get acquainted with the principles and the programming interface. One block I've been stumbling into is that when I open a package via `guix edit $PACKAGE`, I can't go to definitions via `xref-find-definition`. Do you have any advice how I can have this functionality? <lechner>civodul / looks great! although, please omit the acknowledgment. with the 24th approaching rapidly, i would merge right away. life is too short and your git access isn't going away <lechner>actually, i did meet a fellow once with a Perl tattoo <lechner>Kolev / please have a look at 'string-join' in the Guile manual. it will "intercalate" spaces for you <lechner>Kolev / also, you may find that naming sub-expression before use via let (or let*) will make your code easier to read <lechner>as for 'system', you are not using any features that use shell expansion. it would be much safer to use system* with a plain list <lechner>i.e. (system* "docker" "run" "-t" "-v" (string-append (getcwd) ":/work") "-u" .... <lechner>you also don't need the 'main' part. that's mostly useful if you want to also export your code as a module (which is almost never the case with things in /bin") <lechner>without 'env' you are looking at Guile's meta switch. that only matters when you package for Guix, which requires absolute paths in the #! pound pling or use /run/current-system/profile/bin/guile <ieure>Kolev, You might look into udisks, it's a D-Bus service that handles mounting/unmounting disks, making the mount points under /media for you, etc. <ieure>It's the backend used by Gnome, any disk stuff in there is handled by UDisks2. <Kolev>ieure, thanks! I don't currently use Emacs as my shell, but I want to in the future. <efraim>huh, it looks like the vim-build-system forgot the tests? flag <attila_lendvai>Kolev, excelent! :) a couple of advice: (car (cdr ...)) is much more readable as (second ...). it's best to mark "global" variables (i.e. mount-point) in their name; in scheme they usually use %foo to make them distinct. but anyway, good luck on your way towards lisp proficiency! :) <Kolev>attila_lendvai, `second` is a thing? <attila_lendvai>Kolev, right, it's in some of the SRFI's, not in plain guile-user <lechner>Hi, does anyone use PATH separators other than ":" ? <Guest14>Someone knows how I can debug, that guix is waiting for a partition to show up and crashes to guile? I can't even use my keyboard and it is just a guile repl. <ieure>lechner, You're taking about the PATH environment variable? <lechner>ieure / or any of the common search path variables <yewscion>The issue is, when I reboot the server now, it fails to boot. If I respecify the same configs with the root slash included, it will boot fine. Is there a config option somewhere that might have changed? <lechner>yewscion / isn't the whole /gnu/ prefix missing? <yewscion>It is, but I think that the issue comes from the store living on its own partition: If we're talking about the filesystem itself, it would just be a root slash. If we're talking about the ending filesystem, it would indeed be /gnu/ that is missing. <lechner>yewscion / okay, in that case your kernels are missing a --root=X argument <lechner>how does the boot fail, or rather when? <lechner>at insmod, or when looking for the root file system? <lechner>i am not sure anything changed but you can see 'root' in line 252 of your grub.cfg <yewscion>So the rub there is I'm dumped to a grub shell, but not a grub rescue shell. So I think it is when looking for the root file system <yewscion>Ah, okay. I'm rebooting it again now, so I can better report the issue. <yewscion>So, in one of the consoles I have one piece of feedback I haven't mentioned, which is: `error: variable 'prefix' isn't set.` <yewscion>The error is apparently occurring in the if block which ends on line 13; I get an error once I paste that: `error: unknown filesystem.` <lechner>yewscion / the key here is that you don't make it into the initrd. on that note, i'm not sure our initrds support a separate store path but other people do that too, i think <yewscion>Interesting. The reason I have them on separate partitions is a money-saving thing, or I'd just use one big partition. I'll have to do some more thorough searching, I guess. <lechner>i am not sure it finds your grub.cfg <lechner>do you see a /boot folder on 9f120675-e132-4f0a-9ddb-55cc8dd57d75 ? <yewscion>lechner: No, there is no /boot on 9f1296, that's on a different partition. It might not be finding the grub.cfg, but even if I set the configfile manually, it still complains that the paths as supplied are invalid files. <lechner>i had an active Guix server on Linode for over a year but then bought a static IP <lechner>if you are in a regular grub shell it means that 'insmod normal' succeeded, so it finds some modules (although not necessarily the ones you think it should find). do you have another OS on that linode? <yewscion>I do not, but I did use the debian→guix workflow to originally install it. <yewscion>So, the original OS was debian, and I suppose there could be some state somewhere. <lechner>no the issue is that Linode provides a non-standard EFI setup but i can't find the documentation right now <peanuts_>"How to Manage the Kernel on a Compute Instance | <lechner>i can't remember the details but it's some kind of GRUB EFI chainloading think <yewscion>lechner: Yup! GRUB 2 is my current selection. <yewscion>Interesting, so maybe chainloading to the grub on /boot would help? <lechner>i cannot remember. it's really whacky <yewscion>I have to run for now anyway, so if I figure it out later I'll share here. <lechner>sneek / later tell yewscion / somehow it's getting confused by your setup. perhaps it cannot find your boot.cfg <lechner>sneek / later tell yewscion / i believe the boot drive in the Linode setup screens is set incorrectly <attila_lendvai>i have exported some definitions from (shepherd support), and they have showed up in the start/stop GEXPs of my service. is this expected? why? it has surprised me for sure, and i can't seem to find out why it happens. <attila_lendvai>ACTION kindly pings civodul to ask whether this is expected or not <attila_lendvai>these are some logger definitions that i wanted to define in shepherd, only internally <civodul>attila_lendvai: yup, (shepherd support) is imported by the config code generated from (gnu services shepherd) <civodul>it’s the opposite even: ‘make-user-module’ in (shepherd support) does *not* include (shepherd support) <civodul>IOW, (shepherd support) is not imported for config files, by default <attila_lendvai>some services explicitly import (shepherd support) in the module field of a service <attila_lendvai>civodul, is there any re-exporting of the entire support module by any chance? e.g. by (shepherd service)? <civodul>no, it must be explicitly imported somewhere <attila_lendvai>it's something fishy... one definition is a function, another is a macro. and the error i get is: Wrong type to apply: "#<syntax-transformer log.debug>" <attila_lendvai>it's something like this: at compilation one definition is active (function), and at runtime it finds the syntax-transformer in the bindings table <attila_lendvai>i see a warning like this: WARNING: (#{ g108}#): `log.dribble' imported from both (guix-crypto utils) and (shepherd support) <attila_lendvai>maybe it's something at the time the .go files are loaded, not when they are compiled