IRC channel logs
2023-12-21.log
back to list of logs
<qrpnxz>That could be nice for managing software without privilages <vagrantc>yeah, you can install individual packages using guix on top of another system <vagrantc>sometimes there are weird interactions between the host system an guix ... but for many things it works quite well <vivien>csantosb, almost, it’s bug-guix@gnu.org <qrpnxz>huh, I'll check that out. Thanks, vagrantc <vagrantc>i maintain a guix package in debian to support exactly this sort of thing <qrpnxz>vagrantc, can guix bootstrap so that it maintains itself? :D <vagrantc>the first thing you typically do is run guix pull, which essentially is it's own guix install <vivien>qrpnxz, I would not consider guix to be “bleeding-edge”. Also, programs freeze in all sorts of distributions. <vagrantc>the frequency of packages have no substitutes and are unbuildable makes it feel pretty bleeding edge for some ... and i'm a guix enthusiast :) <vivien>I’m another guix enthusiast, and seeing some version numbers of popular packages makes it feel pretty stable :) <vagrantc>and i need two hands to count the number of times i've "guix pull" into a broken guix <csantosb>vivien: correct, thanks. Done. Free format, as I see. <vagrantc>all depends on what you mean by stable ... but comparing it to debian stable ... it certainly feels bleeding edge. <jackhill>ha, I'm looking at what it would take to update openssh to 9.6p1, but the test suite fails. Looking at the release notes, I see "A number of fixes to regression test reliability and log collection." <vivien>(you were expected to read “outdated” when I wrote “stable”) <qrpnxz>I downloaded guix binary distribution... interesting :) Gonna have to pull out find tool. <euouae>You can shutdown with `guix power-off herd` but how do you reboot? :) <ieure>vagrantc, Guix is weirdly inconsistent, lots of things are much newer than Debian, but not: Gnome, Node, Python, gtk, glib. I'm sure plenty of others, but those are some I've encountered. <ieure>ex. my work uses Python 3.11; Guix has 3.10. welp <qrpnxz>i braved the system install with root script. It went... totally smooth and fast lol. Hopefully if i reboot everything is fine. <vagrantc>jackhill: yeah, i have heard a few reports of frustration ... but most of them do not file bug reports :( <vagrantc>jackhill: that exact same issue is present in guix when you first run guix pull on a fresh install ... nothing specific to debian <Kabouik>This is the first boot, still need to reconfigure for the first time and install Wayland/Sway and everything on it. <oceane>uhh on the luks passphrase problem, i'd argue for a passphrase with words picked pseudorandomly from the wiktionary <oceane>the french one has about 400K words and expressions, which means that a 5-words passphrase has 400K×5 possibilities <euouae>My setup is supposed to be 2 partitions, boot and root; root is encrypted; inside there's a swapfile <euouae>the $uuid given by grub is the uuid of the decrypted /, and I don't understand which part of the process fails <jackhill>vagrantc: indeed. If I knew of a solution we could implement it, but I don't. If we can pay attention and fix problems that we notice others having that would be pretty cool. This "too many papercuts" happens too often. <euouae>oceane: 5 words from a 400K dictionary is roughly as strong as 9 character a-z password <euouae>or sorry, a 20 character a-z password. my calculator misinterpreted my `.` <euouae>That's assuming someone knows you're using that 400K dictionary. Maybe it's a good system actually. Nevermind me. <oceane>`10240000000000000000000000000` doesn't seem like a 20 characters a-z passwords <oceane>for some reason i can't do powers in calc using exwm, but according to my last calculations, it was equivalent to a 20-characters ASCII password <oceane>iteratively dividing this by 127 like a cavesperson makes it lose two digits per division, which still makes a 15-characters ASCII passphrase, sorry <euouae>oceane: I just solve 400000^5 < 26^x <oceane>anyway, iteratively add words up to 7 or 8 words and you get the entropy of a 20-characters ASCII password <oceane>euouae, i don't, because i'm a sociology student <oceane>students in my prom are panicking over quartiles <euouae>I think your system is good I cast doubt over it to double-check it but it's not a bad idea <oceane>anyway i think it's easier than having to check where the fuck is the % character on a qwerty keyboard <rebiw>Anyone using guix home to modify .profile ? I'm having an issue where I can't put content before the on-first-login script. It always comes on top of .profile, and I'm unable to write content in .bash_profile before the source .profile line. <rebiw>I know I can use home-files-service-type to write the files manually but I was wondering if there is another way. <vagrantc>davidh38: guix does use shared libraries, but not in the system path <davidh38>vagrantc I thought every application has it's own libraries <vagrantc>davidh38: every application is explicit about which libraries it is linked against <vagrantc>davidh38: and it is possible, even desireable, to link to the same libraries, to get the benefits of shared libraries <vagrantc>and for the most part, all programs built form the same guix pull generation should mostly use the same libraries ... there are probably some weird corner-cases but for the most part that should hold ... <davidh38>vagrantc are the shared libraries in a particular folder? <vagrantc>each program explicitly links to it rather than looking in a search path <davidh38>vagrantc how does the other programs know, that the libraries they are using already exists ? <davidh38>when they are not in a particular folder, they need some program folder to be placed in <davidh38>at first at least, do I understand that correctly? <vagrantc>davidh38: i do not think you understand correctly <vagrantc>each program knows exactly where to look for each library it uses ... and if two programs happen to be using the same library at the same time, they load it into memory only once <vagrantc>this is, of course, a bit of a simplification <vagrantc>each program is built with a hard-coded list of paths to each of it's libraries at build time ... it does not need to search for them <vagrantc>this is very different from more conventional distros, such as debian or fedora <vagrantc>which rely on the libraries being it a predictible set of directories... <vagrantc>guix/nix are just a fundamentally different paradigm <davidh38>vagrantc how does another program know, that a library already exist on my guix system <davidh38>vagrantc let us create an example: program A is installed watch lib1 in guix. After that program B will be installed in guix, which also uses lib1. if lib1 is not in a particular folder, how can program B know this. What happens, program A is deleted. How is lib1 for program B preserved? <vagrantc>guix only garbage-collects things not referenced by anything else ... <vagrantc>so regardless of which order you install it, it would only remove the library when nothing references it <davidh38>vagrantc so if I delete program A, it will be deleted except lib1? <vagrantc>davidh38: also, lib1 is, in a sense, installed in a particular folder for a particular exact generation of guix <vagrantc>most things in guix are installed in /gnu/store/SOMEBIGHASH-PACKAGE-VERSION/ ... where SOMEBIGHASH is a hash of all the other things in guix that it depends on <vagrantc>davidh38: typically in guix, uninstalling something just removes symlinks that make it available in your search paths ... the stuff in /gnu/store/* typically stays there until you run "guix gc" ... the garbage-collection i mentioned earlier <vagrantc>and even then, because guix typically just builds a new generation, you have to delete old generations of installed packages before guix gc will delete the actual files in /gnu/store <davidh38>vagrantc okay, so, if I garbage collect, and the lib1 is still use, does guix then delete program A, but not the lib1 org does the garbage collector just sees the reference for the lib1 and then leaves program A where it is <vagrantc>davidh38: guix is, in some ways, just a bunch of files in /gnu/store and some utilities that make symlink farms referencing all that stuff ... and a way to manage what should be kept, deleted, etc. <vagrantc>davidh38: if nothing references program A, but something still references lib1, it would delete program A <vagrantc>davidh38: do you have something specific you are trying to achieve, or just wrap your head around guix? :) <davidh38>vagrantc thank you some much, that really helped. <vagrantc>i may have knowingly or unknowingly told a white lie here or there, but i don't think anything too misleading :) <davidh38>vagrantc I wanted to know, how guix works behind the scenes <davidh38>vagrantc even if, that helped me more :) thank you. where did you get that knowledge? <davidh38>vagrantc would you recommend some reading? <vagrantc>i don't recall reading anything specifically ... mostly just dive in and ask questions in irc like you're doing :) <vagrantc>"guix help" and "guix help COMMAND" goes pretty far ... occasionally poking at the manual <vagrantc>seems to just parrot urls, sometimes with a little extra info ... <rebiw>is there a way to set xdg_runtime_dir using guix home? I have tried modifying .profile and .bash_profile but the on-first-login script always run first in those files. <vagrantc>davidh38: i think i watched a talk from ludo back in 2015 or so and downloaded the installer and poked around a bit ... and then set it aside for another year or two before i started actually playing around with it for real <davidh38>vagrantc thank you, I will check out the talk and I think, I should also be starting to play around <qrpnxz>i'm back. Trying to figure out how to install something without root now <qrpnxz>i believe the key is something called "guix home" <qrpnxz>i'm scared guix is gonna corrupt my local config <qrpnxz>😆 actually what I started doing 😆 <qrpnxz>i haven't backed-up in too long anyway <qrpnxz>probably gonna take some hours 👀 lot of data <apteryx>that's good. I'm a happy hourly btrbk snapshotter (+ daily backup) <qrpnxz>heh, i've wanted to do something like that. But not btrfs i don't trust that thing <davidh38>Is there a laptop, that runs good with guix? I might want to buy a new laptop, but it should run with on guix without problems <qrpnxz>i know hardly anything that will run a dfsg compliant system, or with wifi that isn't broken. Interested to hear what ppl suggest <ecbrown>anything if you buy a usb wifi dongle <qrpnxz>so guix will actually install and run will on like an off the shelf xps 13 or something long as you use dongle for wifi? <ecbrown>it might not have working bluetooth though <qrpnxz>i didn't know the graphics situation was much better <ecbrown>might try to find something with intel graphics <ecbrown>proprietary chipsets, its a linux libre thing <davidh38>Is there on chipset, that is not propietary? <davidh38>hmm, that is very unfortunate, because wifi is nice to have on a laptop <apteryx>I've used that one successfully in the past, but it's not working at the moment, appears to be some hardware failure. <davidh38>I really want to build a laptop with guix on my laptop. I already have it on desktop <davidh38>I just need to get some other things running, but i think I can get by <jackhill>qrpnxz: :) (it was ext4 that had the data eating bug recently though) <qrpnxz>i'm open to reconsidering the FS. When I last researched btrfs it looked immature. Now it has been some years. I don't like to get clever with storage. I have an lvm set up that is quite flexible, but gosh if i had to reconfigure it would take me days of re-reading man pages. And then moving the data around takes ages. And I don't want to lose my data. Let's just say long story short I'm CONSERVATIVE :) <qrpnxz>if this guix thing works out (and I have a feeling it will), that will ease my mind because re-setting up a system just how I had it should be much simpler. At best, just copying a script. <jackhill>qrpnxz: for sure, definitely don't need mean to pressure to switch (although I quite like the flexibility btrfs brings), but I was amused at the etx4 bub (c.f. https://micronews.debian.org/2023/1702150551.html ) so wanted to share my amusement. Presumably I was only amused since it wasn't my data it ate. <jackhill>oh, and yes, re-setting up systems is awesome with guix! <qrpnxz>i wonder what kind of level of detail/configurability the guix scripts will give me. One thing that I do on set up for Debian is set the default system mask to not let everyone read everything by default. <qrpnxz>i know one thing you can specify is users and groups <qrpnxz>"Once the configuration looks good, you can first test it in a throw-away container: guix home container config.scm" <jackhill>is there an recommended way with gnu-build-system to not run the test suites in parallel? <iyzsong>jackhill: it accepts '#:parallel-tests? #f' as an argument <jackhill>ah, and now that i know found it in the code an manual <jackhill>This was an amusing line to come accross in my grepping though: "gnu/packages/webkit.scm: ;; The build may fail with -j1 (see:" <jackhill>iyzsong: thanks again, that allowed me to submit a patch #67948 <alexey`>@theesm: Thank you. Let me be a little more specific about my setup. I've got a <alexey`>dual PIII server with an old GDT SCSI hardware RAID controller. It's a museum <alexey`>machine but it is still operational and does its job well. Linux developers <alexey`>removed code for this controller (gdth.c, gdth.h, etc.; module `gdth') from <alexey`>kernels greater that 5.10.X on the grounds that nobody used the <alexey`>hardware. Actually, that's not true. At least one dinosaur is still alive <alexey`>:). Besides this machine, I've got some more, which run Debian GNU/Linux with <alexey`>the i386 and amd64 linux-libre kernels. My provider offers unlimited <alexey`>traffic, but once you've downloaded around 50-80G, the speed drops from <alexey`>900Kib/s to 100-200Kib/s or, worse, to 14Kib/s. Yes, it is unlimited, just <alexey`>14Kib/s :). Because I have several machines and unstable traffic with speed <alexey`>fluctuations and interrupts, it makes sense to host a separate local repository <alexey`>of Debian for i386 and amd64 architectures and update it once in, say, two <alexey`>weeks, which is what I try to do. But it turned out that downloading around <alexey`>100G per an architecture at 14Kib/s is very time consuming: the Debian mirros <alexey`>get updated faster than my downloading ends. That made me think about dowloading <alexey`>just sources and build the operating system locally. The Gentoo offers this, <alexey`>but as I wish to run the GNU software, I thought that the GNU Guix system may <alexey`>offer the same with all the Guix's advantages. However, by default, the stable <alexey`>version (1.4.0) image of the GNU Guix system require downloading 5.10.35 linux-libre <alexey`>kernel, which is already gone and the installation crashes with error <alexey`>messages. The logs showed that all GNU Linux libre servers had been <alexey`>desperately searched for the 5.10.35 kernel and because it had already been <alexey`>removed from the mirrors, everything just crashed. The solution to this <alexey`>particular problem seems to be adjusting the Guix's default settings so that it <alexey`>doesn't require software, which is no longer available. Being a novice, I <alexey`>cannot do this myself at the moment, because studying GNU Guile and the Guix <alexey`>manual takes some time. Anyway, thanks for your support and forgive me <efraim>for debian and derivatives I'd suggest apt-cacher-ng. You'd use one machine as a proxy for the others and when you download the .debs it'd either download from the cache because you'd already downloaded it or it'd save it there for the next machine <efraim>for guix you can use guix publish to share derivations (packages and sources and such) between machines so that each one could download from the others <apoorv569>How does guix publish work? Like if I publish my store over HTTP, how does the other system know if can connect to a local store? <alexey`>@efraim: guix publish is a very useful feature. Really cool. Thanks. <the_tubular>Since I turned on X11, It keeps hardreezing randomly <oleander>Also, do you have any suggestion to improve my code or it's fine? One thing I never figured out is how to log into the system automatically without a display manager. I found this config https://gitlab.com/mbakke/guix-sway-example/-/tree/master but don't know if it still works and I need some time to study/understand the code before merging some of it into my config without creating a mess. <sneek>Welcome back oleander, you have 1 message! <sneek>oleander, unwox says: there is openfortivpn package, maybe it is what you need <euouae>I'll be trying again by removing some of the parts of the configuration to see where I'm getting stuck. <euouae>okay, it was an error in file-system actually. "When the source of a file system is a mapped device (see Mapped Devices), its device field must refer to the mapped device name—e.g., "/dev/mapper/root-partition". This is required so that the system knows that mounting the file system depends on having the corresponding device mapping established." <lechner>euouae / grub can only do a particular version of luks <euouae>but I thought I could have boot unlocked <euouae>I was not expecting GRUB trying to unlock /dev/sda2 <euouae>ah yeah, the kernel is in /gnu/store. That's it. <euouae>I'm reading some e-mails from help-guix <jackhill>euouae: I, unfortunately, don't have a link handy, but set up an activation script that would copy the kernel and initramfs to /boot. I've never played with that thought, but maybe it will help your search. <euouae>jackhill: I thought that another alternative is to boot from USB on a different kernel and kexec. kexec was recommended from #linux. Not sure how far that'll get me <jackhill>yeah. Long term, I hope grub's luks support to improve <jackhill>obviously we need a bootloader written in Guile ;) <euouae>the bootloader would have to embed the guile VM in it right? <euouae>because there's no native compilation yet <ulfvonbelow>the funny thing is that the pieces of grub are soo close to making it so that a well-written embedded grub.cfg could read a password, use it to decrypt luks partitions, then pass the password into the initrd as an "extra" initrd appended to the main one <ulfvonbelow>it's just missing a way to pass a string literal to the initrd command or create a temporary in-memory file <ulfvonbelow>if it's in the store, I think modifying it in-place would be A Bad Idea <euouae>initrd is made by mkinitcpio right? <ulfvonbelow>strictly speaking I think it's made by the build-initrd procedure of (gnu build linux-initrd) <euouae>"This" being the unavailability of argon* <euouae>"Adding it in the future would be trivial" <euouae>There's a coupe things I noticed online <euouae>1) arch AUR has a patch for grub+argon and 2) some reddit user had a nixos "graft" to make it work <euouae>maybe that's the way forward? copy that kind of thing and bring it to guix? <ulfvonbelow>on an unrelated note, has anyone else had trouble printing pngs? I can print a test page from the cups admin page just fine, but when I try printing a png it spends a long time with no progress, then says it's completed (meanwhile nothing has happened at the printer other than the display saying "receiving data" for a long time) <ulfvonbelow>wondering if it could be an issue with the filters, but I don't see any relevant messages in the error log <euouae>do you think I should bother trying to do this sort of thing ulfvonbelow ? <jackhill>yeah, I don't know, I'm just much more comfortable working in Scheme than C. Maybe Guile-Steele or Guile Hoot will come to the rescue for native comp. <euouae>It'll happen eventually but I don't think I can do anything on that end jackhill <ulfvonbelow>I would think that just adding a patch to the grub package and checking that it works shouldn't be too terribly difficult <qrpnxz>I did "guix install hello" without root. It. Just. Worked. 😍 <apteryx>is anyone using /etc/xdg/autostart/some-entry.desktop with Guix System? <ieure>apteryx, I don't; I have Guix Home services that run things on login. <ieure>I believe the Guix Cookbook has a recipe for this. <apteryx>can't find a mention to 'autostart' ther <ieure>Because that's an XDG term, which this isn't. <apteryx>OK. I need it global for my use case (applied to all users) <apteryx>perhaps it's already handled by the XDG variables and the desktop environments <apteryx>e.g. adding a package containing etc/autostart/entry.desktop to my operating-system's packages list <ieure>Why do you need it started for all users? That is, generally, not how Guix likes to do things. <jackhill>woo, #67938 just turned green! It would be nice to get that and #67948 reviewed if anyone has time since they have some security fixes <apteryx>it's a script that should run at login time for our vm-image.tmpl image, to help with display resizing in a SPICE viewer <podiki>jackhill: both patches for master? quick look seems good, i'll double check later and can push <jackhill>podiki: yes both for master. It looks like both were under the rebuils threshold :) Thanks! <euouae>jackhill: what did you mean by "Sending again as I put the wrong branch prefix in the fist mail."? What branch prefix? <podiki>jackhill: patches looks good, just added a period on a commit message and tweaked the url format in a comment. just building openssh locally and then will push today <ieure>jackhill, Does the libssh need a graft to update packages that depend on the old version? Or is this going to rebuild those? <podiki>this will rebuild all libssh dependents though guix refresh doesn't list too many; and qa rebuilds also just a few dozen <podiki>openssh looks like it has < 200 as well <podiki>ieure: we graft when we don't want/can't rebuild many dependents, but these are all within what we consider fine <podiki>ieure: in the case of something like curl, with ~22k dependents (if I recall), we would graft instead on master (and then actually do the update on a branch for instance, to build substitutes first) <podiki>ACTION lunches; will push those patches after <ieure>podiki, Okay, thanks for the explanation. <qrpnxz>i need to remember telling guix to use more cores <davidh38>I have a weird sound problem with chromium, it is really strange. If I open youtube, the sound does not work in guix. But after playing an youtube video with icecat, it works on chromium. Does anybody have any idea, why this could be? <Rovanion>davidh38: Something something bus activation? <qrpnxz>apteryx, building things. I install something or do pull and it takes eternity and using little to no CPU that i can see <apteryx>most build systems default to use as many cores as available <Rovanion>I'm just throwing ideas out there. I'm thinking Icecat activates/sets up the sound system thruogh d-bus or something. <apteryx>oh yes, icecat is configured to let pulseaudio to autospawn, while chromium appears to assume it's already there <apteryx>so if you start something like pavucontrol (which will spawn pulse) before chromium it'd work <apteryx>this appears to me a chromium bug (I think I've seen it upstream somewhere before) <qrpnxz>Snikket iOS client is GPL 3. How are they publishing it on the app store? <davidh38>apteryx can you explain please, what you mean by upstream exactly? is this a certain branch? <davidh38>I heard the term very often before, but I never got by what is meant by that <qrpnxz>i've been guix pulling for almost two hours. Doesn't seem parallel at all. <davidh38>apteryx should I do guix pull to fix this? <davidh38>apteryx ah, I got it, upstream is the chromium repo and downstream is the package for chromium in guix <davidh38>apteryx so that means, I would need to package chromium again, right? <apteryx>not a bug of the guix packaging of it <davidh38>apteryx so I need to wait until the bug is fixed and then package again, right? <apteryx>yeah, we'd need someone to come up with a fix <apteryx>then it should be submitted to chromium for inclusion, and could be carried in the meantime as a patch for the ungoogled-chromium package in guix <davidh38>apteryx if you know, that this is something with the bus, would you know a better workaround than starting icecat? <efraim>not technically different but it should be faster to load <davidh38>-@efriam it is good, I can put it into my autostart, thank you. Would you explain please, why pavucontrol works? <efraim>pavucontrol controls the audio levels through pulseaudio, so it'll also start pulseaudio <rekado>qrpnxz: “guix pull” should not take 2 hours ever. Are you building everything from source? <qrpnxz>yes i'm building everything. Yes i know that takes a long time, but i also have a powerful machine with many cores and ridiculous ram, but if guix isn't going to take advantage it's very sad <ieure>qrpnxz, Have you run htop to see whether you're saturating your CPUs? <qrpnxz>not even close. guix is near zero always. I see guile is called, also makes little use of the compute <ieure>Hm, I've definitely saturated all my cores building large projects. <efraim>compiling the guile modules of guix can be slow <qrpnxz>i think i need to do like -c 16 in the future or something. Some said it should be automatic, but it don't seem to be <ieure>Compiling C / C++ tends to be bursty due to the nature of the toolchain. Guessing that even though individual packages build in parallel, you can't build multiple packages in parallel. That'd probably even things out a bit. <qrpnxz>i would hope independent packages build in parallel <ieure>I don't know if Guix does that or not. <rebiw>Is it possible to create a file-like object out of multiple local-file or plain-file calls? mixed-text-file is the closest way I found but it creates a computed file object. <ulfvonbelow>the number of possible simultaneous builds is determined by the number of available guixbuild* users (e.g. guixbuild01, guixbuild02, etc) <ulfvonbelow>by default I believe only one concurrent build is done, but this can be configured with the --max-jobs option to any commands that can start builds <apteryx>does sourcehut have an issue tracking feature? <ieure>I think so? I tried it once and found it baffling and impenetrable. There was no way to delete my account, so I emailed the guy, and he was like "Really? Do you really want me to delete it? It's a very manual process and I don't like doing it." <qrpnxz>apteryx, yes it does, as a mailing list <qrpnxz>they are geared for git send-mail workflows <podiki>efraim: hey, did those mesa builds ever finish on powerpc64le, and I forget, arm64? <efraim>for mesa? it was powerpc-linux (32-bit) and riscv64-linux, they both finished succesfully <qrpnxz>ulfvonbelow, thanks i think that max-jobs option will be the key. I did see several of those users being created by the guix install script <podiki>efraim: yes, thanks. QA hasn't processed the branch still so I'm just guessing based on the 61% coverage on berlin that things are nearly there (I've restarted a lot of x86 builds manually and made good progress through that) <efraim>I didn't test aarch64 but I can do that and armhf <podiki>thanks. yeah only updates are xorgproto, mesa, xwayland, and curl <podiki>xorgproto being the high impact one (which mesa also depends on of course) <efraim>I'll build that list on riscv64 first and then on aarch64 <podiki>I just merged master into mesa-updates and I'll send a message to guix-devel later today <jackhill>podiki: thanks for the reviews and commits! <podiki>it would be good to have any "security fixes" patches cc'ed to security team, maybe just a quick thing we can do with the current teams cc'ing framework? <euouae>Hello, the guix package definitions are under guix/gnu/packages and grafts in guix/gnu/packages/patches right? <sneek>euouae, jackhill says: if you look at the subject of https://issues.guix.gnu.org/67938#0 you'll see that it says, "[PATCH core-updates-frozen]…" the core-updates-frozen within the square brackets is notiation for which subproject or branch the patch applies too. I accidentally sent it with an old git config. See also Specifying a sub-project https://git-send-email.io/#step-5 <euouae>jackhill, thanks for clarifying! <euouae>Back to my question, if that is so, where is the definition of the grub package? I can only find something under guix/bootloader/grub.scm <podiki>gnu/packages/patches just has, as you may guess, patches that are used in package definition, see the source patches part of some packages <podiki>so a graft means a replacement is used for a package, wherever it is referenced by another package the path /gnu/store/<hash>-<package>-<version> is replaced with the path to the replacement <podiki>so packages aren't actually built against the replacement, the build is unchanged, merely references to that now replaced package are changed <euouae>and what about the grub package? where is it? <podiki>and you'll see the location field will tell you <efraim>I've updated my local branch of mesa-updates and I'm building now <podiki>you may even be able to click on it (depending your terminal emulator) to go to the actual file and line; it won't be editable <podiki>efraim: and feel free to let me know of anything I need to investigate or if we need to restart builds on berlin <euouae>say I want to modify the hello package <euouae>do I pull in the source code from the /gnu/store with guix archive or do I pull from the official repo of the hello program? <efraim>podiki: riscv64 is good on those 4 packages <efraim>at least they build correctly that is <euouae>ah no -- I need to pull the source code from whatever source the official channel pulls from <podiki>you can use "guix build --source <package>" <euouae>does that build it or just fetch it? <apteryx>in other words, the source archive that the package was built from <podiki>but not other modifications that might be made during building (e.g. sometimes we manually adjust paths or strings at some point in building) <euouae>ah it seems that I don't need to go as far as defining my own channels, etc <euouae>I can just use `guix build --with-patch=hello=mypatch.patch` right? <efraim>podiki: powerpc64le builds those 4 packages <qrpnxz>maybe i should ^C and re-run with better job count, but man if it doesn't work and i have to wait another 4 hours i'll be sad <euouae>very simple to apply patches! nice <euouae>so it seems that the workflow for working on a package does not actually require writing your own channel or package definition <euouae>(unless the package is not already in the guix package list) <euouae>very cool. Tomorrow I'll look more into GRUB, today I successfully patched GNU hello :P <euouae>Maybe argon2* is possible in GRUB. <qrpnxz>oh, i had my terminal read only lol. Was able to restart it now. Hopefully it is faster <qrpnxz>it seem continue where it was without issue <jay2>Greetings! Any pointers to what might cause the error "source expression failed to match any pattern"? I'm trying to (modify-phases ... (replace 'configure ...)) in a package definition <civodul>jay2: hi! it’s a generic and admittedly cryptic error saying that a macro is not being passed what it expects <civodul>in this case, it means that that follows ‘modify-phases’ doesn’t have the expected shape <jay2>ok, so basically what I expected <civodul>if you want you can paste the code you have <jay2>I'm somewhat copying from the cookbook, can that have old code that has the wrong shape? <jay2>dumb question before I paste, how bad is a multi line paste going to be garbled? <jay2> #:phases (modify-phases %standard-phases <jay2> (lambda* (#:key outputs #:allow-other-keys) <jay2> ;; Run mconfig and set the correct prefix <jay2> (let ((out (assoc-ref outputs "out"))) <jay2> (invoke "./mconfig" "--prefix" out) <jay2>huh, did not expect multiple lines to work.... anyways, theres the :phases block that is causing me trouble <civodul>jay2: usually, it should look like: (package … (arguments (list #:phases #~(modify-phases …)))) <civodul>notice the #~ before (modify-phases …) <jay2>thought I'd snip to the relevant parts <jay2>The exact error is: error: (%modify-phases phases* (replace (quote configure) (lambda* (#:key outputs #:allow-other-keys) (let ((out (assoc-ref outputs "out"))) (invoke "./mconfig" "--prefix" out))))): source expression failed to match any pattern <jay2>I figure based on the error that something in modify-phases is the culpit <civodul>yes, but i fail to see what’s wrong with this one :-) <civodul>it works if i pass it to the macro expander <civodul>ah yes, so it’s missing #~ before ‘modify-phases’ <civodul>#~ indicates that the code that follows is “build code”: code that will run if and when you actually build the package <jay2>so code that is being passed to the daemon process? <jay2>so just literally #~(modifiy-phases ....? <jay2>is that a Guix thing, or a feature of scheme? I'll make a note of the syntax for myself <qrpnxz>on my debian laptop i see guix putting in work. Maybe it's a fedora thing that is making guix not perform quite how it should. I had to make selinux permissive just so it could work, and i still get selinux alerts periodically. <qrpnxz>currently it is building glibc-mesboot, i think <jay2>unfortunately that did not make a difference, but atleast I've learned something <jay2>civodul, Thanks for your help, #~ was in fact the answer, I just needed a (use-modules (guix gexp)) to go along with it <jay2>The next error is tomorrow's project, bye! <qrpnxz>coming up on hour six of guix pull <rekado>if you’re building *everything* it’s going to take much longer than six hours. 
