<jts>Hi. I'm trying to configure GRUB to recognize another OS installed on a separate drive from Guix. Do I just do this through the traditional GRUB files and tools, or is there a Guix-specific way to do it? <florhizome[m]>Ithink you should look at the bootloader–configuration field in operating–system, and the docs available for that (or as a last resource, the source). I haven’t though, so far. But I‘d be interested, too. <apteryx>has the intel soundcard bug been resolved in the linux kernel? Something changed; perhaps i should remove "snd_hda_intel.dmic_detect=0" from my config <apteryx>I forgot about it really, but it had something to do with getting either the mic working or having a usuable sound output <SeerLite[m]>jts: Regarding the GRUB dual-booting, I think the usual recommendation is to not mess with it and just use the temporary UEFI boot order override that most boards can do <SeerLite[m]>E.g. on my thinkpad I have to press delete before GRUB shows up to get to a menu that lets me load other bootloaders <jts>Okay, I'll just keep doing that, then. Thank you! ***califax- is now known as califax
<KarlJoad>I am planning on switching my VPS website to Guix tonight/tomorrow. I already have a small config set up. Is there something else I should consider before doing this? <Ribby>Hello, just a question. I have my usb. I tried installing on a 32 bit, the error log mentions "libblkid as missing"? I tried on a 64 bit, installation in blind mode. Usb file size 35 GB. Do I just wait, or I have to read and sign up for a discussion. I am more like to expect a real-time appointment (got enough computer parts). <Ribby>It looks like the installation froze or something. You guys know the system requirements? <KarlJoad>Ribby: The system requirements are fairly minimal. I managed it on a 1 core, 1GB RAM VM. <KarlJoad>That one took a little while. But not terribly long, as there were substitutes for everything I specified. <Ribby>Mines is on a Dell 780, you think guix will install on that? <KarlJoad>But it might take a while depending on the exact system specifications of your machine. <KarlJoad>Biggest issue might be the GPU (if you have nvidia), and the HDD (if it is still spinning metal). <Ribby>Well... the usb did stop blinking during the seemingly install freeze. <Ribby>I don't have nvidia video, but yes, hdd. <Ribby>Will those issues stop the installation process? <KarlJoad>HDD should not, no. But the install will take quite a bit longer due to that. At what point did your installation freeze? <Ribby>It was something like error log libblkkid line. <Ribby>The 64 bit had a blind mode. <Ribby>It's possible that it did not freeze at all, but at least I'm trying to find free time to get guix installed. <KarlJoad>I have no idea what the blind mode is, but OK. <KarlJoad>Due to the symlinks, Guix can take a while to install. This is especially prevalent on HDDs. But, it could be something else entirely, and I have no idea what is going on. <Ribby>It's something with a 64 bit feature. Something about secure boot or udmi/something installation mode. <Ribby>Just how long? I mean, I know it's 35GB for guix alone! I had a ubuntu + tools combo totaling up to 15GB. <Ribby>It didn't take too long though. <KarlJoad>Unless you have a specific configuration, I don't think it should be 35GB right off the bat. I have an install on a 25GB VM disk. <KarlJoad>Even on a full-featured desktop that has XFCE, I am only using 22GB. <KarlJoad>As for secure boot, as far as I know, Guix System does not support that. <Ribby>Well, the usb seems to total 35 GB. I think the disk space is way more than that. <Ribby>Okay, then it's just my instructions with the usb. <Ribby>*the instructions, wasn't me. <Ribby>Okay, I just want to know if you had any error messages and holdups during the installation process? I want to make sure I didn't get a unique problem. <KarlJoad>If the installation USB is totaling 35GB, that seems off. <KarlJoad>I have not had any issues installing Guix System, besides when I mess it up myself. <Ribby>Okay, can you provide an estimate in terms of wait time? <Ribby>I think there is a possibility of error messages at times, but I hardly know of what's really going on. It's technically my first time installing (from the usb). I think I installed on a cd before, but my computer at the time was quite sluggish. <KarlJoad>I just checked, the install ISO is 670MB, so a 35GB install USB could be very wrong. <Ribby>Did you ever install with a usb? <Ribby>Did you ever wait, like, for a day, before the installation requires user input? Estimate of wait time to be exact. <KarlJoad>I installed with a USB, yes. But it was to an SSD, on server-grade hardware. So I cannot provide an estimated wait time. <KarlJoad>Your best bet might be to change to a different TTY and check that the system is actually doing something. <Ribby>I wouldn't have to provide user input during the installation, do I? <Ribby>Okay, then how long was it on a ssd? <Ribby>So it appears that guix is catered towards servers? <KarlJoad>I used the graphical install, and then edited the generated config at the end, so I don't know about user input. But there will be some if this is your first time installing Guix there. <Ribby>Okay, I will just thumb estimate 40 minutes on a hdd. <KarlJoad>I am trying to get it on my VPS hosting my website, I want to switch my laptop to it, I will eventually switch my desktop (the one with server hardware) to it. BUT, it does abide by FSF and GNU ideals of free/libre software. <Ribby>I must have an usb with guix along with packages. <Ribby>By ideals, does that mean there's going to be rules regarding what hardware is allowed? <KarlJoad>Guix/FSF does not _exclude_ hardware, but some HW is less-well-supported than others, e.g. NVIDIA GPUs. <Ribby>I have an intel, but that isn't a gpu, is it? <Ribby>Sorry about that, I went off the rails. <KarlJoad>Depends. Intel CPUs sometimes have a GPU on them too. You have to check your particular computer with its specifications. But, the linux-libre kernel that Guix uses by default should handle those Intel GPUs alright. <Ribby>Have you ever installed Guix on a 32 bit computer/motherboard? <Ribby>I'm probably overstressing the minimal, but I would like to see what limits are there in terms of hardware. I can't say much about the internal process, but at least I can figure out the hardware. <KarlJoad>I have never installed on 32-bit, no. But it should work alright. Guix supports i686, which is 32-bit x86. <Ribby>Okay, good to know. It's just that claims are one thing, but a showcase demonstration is another. <Ribby>Would a dell bootloader interfere with the installation process? Dell is usually a workstation brand so I might expect underperformance with the basic. <KarlJoad>In this case, Guix builds packages for i686, so it works with i686. Dell bootloader may interfere with the boot process, but I don't _think_ it should interfere with install. <KarlJoad>But you mentioned secure-boot, so that _might_ cause an issue. I do not know. <Ribby>I don't have to secure boot, legacy boot works as well, but it will be like a 32 bit scenario I mentioned earlier. <Ribby>Anyways, I think that's enough speculation. Wish me luck on the weekends. <KarlJoad>Yeah, it might take quite some time. If it is stuck I recommend you re-flash the USB and try again. The installation ISO is being rebuilt constantly. <Ribby>Maybe it's just me, but as an user, I sometimes wish for a signal of loading indication. It's a concept of feedback in progress. <Ribby>It's true that newer versions support more hardware and as well as bootloaders. Maybe my usb is a outdated version. <KarlJoad>The 1.3.0 is _very_ out of date. Practically everyone recommends the latest version instead. <Ribby>I had an ubuntu 8, which didn't work for the current ethernet/wifi hardware. I switched up to ubuntu 18 in order to enable access to current standard at the bare minimum. It also supports wine, but windows application have its myriad of old software installation/uninstallation problems. <Ribby>Yes, the ubuntu 18 works on a dell 64 bit like a charm. It's too bad that I couldn't get an OS to work in 32 bit for recent standards. <Ribby>Had some older computers lying around, wanted to make some reuse of them, somehow. <Ribby>Is there such thing as a x86 64 bit? <Ribby>But yes, my usb has a 1.3.0 version. <Ribby>This could be a problem. Is this version around the beta stages? <Ribby>Well, I was hoping for a later stable release? <KarlJoad>There is a 1.4.0 release happening eventually. But there is no later stable release. I personally recommend the latest version myself, regardless of its stability. If passes CI, it is usually good enough to be usable. <Ribby>I'm going to try 1.3.0 first as a standard procedure. <drakonis>all you need is to invoke guix pull and it'll take you to the latest commit <drakonis>guix releases are merely starting points <Ribby>It's a start at the very least. ***duds-_ is now known as duds-
<Ribby>Well, I ran out of computer time. Thank you for your help. <jgart>what do guixers think of making `guix pull --news` report changes from their respective channels? <jgart>for example, when I ran `guix pull --news` just now I get the following: <jgart>2 new packages: go-github-com-gabriel-vasile-mimetype, go-gopkg-in-vansante-go-ffprobe <jgart>`guix pull --news` doesn't tell me what channel those two packages came from <jgart>apteryx, thanks! do you think it would be difficult to implement? <jgart>I guess I should get reading guix/scripts/pull.scm <apteryx>jgart: I haven't touched that part of the code, so I don't know! <jgart>podiki[m], I use dmenu and have used rofi briefly <jgart>apteryx, I'll do some reading first <podiki[m]>I have a package for a rofi plugin, wondering how best to finalize for a guix for rofi to find it <podiki[m]>normally rofi looks in something like /usr/lib/rofi for plugins <podiki[m]>you can set an option when you launch to use something else, but each plugin in guix would go somewhere else in the store <podiki[m]>my current local hack is to run with this variable set to $(dirname $(which rofi))/../lib/rofi <podiki[m]>i.e.: the lib/rofi in the profile that has rofi <podiki[m]>I'm guessing there is no good "global" plugin path that could be set by default in building rofi, for instance <jgart>podiki[m], maybe you need something in guix for rofi like what python has with GUIX_PYTHONPATH <jgart>not sure at the moment what would be best <podiki[m]>thanks, I was proud of that (for one that is very limited in shell stuff) <podiki[m]>well right now I think this might be the first rofi plugin? so I don't know if I want to jump right to that extra env wrapping <jgart>I'm not too familiar with the rofi plugin ecosystem <jgart>Feel free to send new wiki patches to ~whereiseveryone/guixrus@lists.sr.ht <jgart>Some of those might make it to upstream docs and if they do I'll attribute the original sender of course <jgart>I review wiki patches within a day <podiki[m]>been meaning to collect all the random tidbits I pick up, usually I keep a running notes file but haven't <podiki[m]>hmm..no easy solution is coming to me...maybe not worth it for just one plugin so far <jgart>maybe send a msg to guix-devel <podiki[m]>yeah, could be a more general question of handling plugins for programs <jgart>podiki[m], do you happen to understand resolve-interface? <jgart>#<procedure resolve-interface (name #:key select hide prefix renamer version)> <jgart>Find the module named name as with resolve-module and return its interface. The interface of a module is also a module object, but it contains only the exported bindings. <jgart>just trying to understand when I would need that. There's no other docs but what I pasted above <jgart>I should just read more code now <podiki[m]>maybe you are right about the path env for rofi (I'm guessing this is similar to the python one): patch rofi to also look at e.g. GUIX_ROFIPLUGINPATH and each rofi plugin has that as a search path in package def <the_tubular>Anyone is using Emacs Application Framework on guix ? <jgart>podiki[m], cool! sounds like a plan <podiki[m]>anyway, perhaps not bad once I see it in the cold light of day, catch you later! <podiki[m]>(oh I guess only rofi needs that, so then that env will be set by the profile, knowing to look in that profile's lib/rofi for plugins. i think. really night now!) <Guixie-shmiexie>Hi, guix! How can I enable ssh server (from guixPM) on foreign distro (Debian)? systemctl status shows that ssh.service couldn't be found <jgart>wdyt think if `guix pull --news` reports changes from their respective channels? <civodul>well, except when listing new/upgraded packages <florhizome[m]><podiki[m]> "I have a package for a rofi..." <- btw, rofi‘s wayland edition sits on guixrus. <florhizome[m]>I kinda doubt it has no env vars at all you could set with search paths, need to look. rofis man is very extensive. <jgart>for example, when I ran `guix pull --news` just now I get the following: <xelxebar>Could have sworn I saw Guix Past stuff appear in the new packages section when I first added the channel a few days ago. <jgart>2 new packages: go-github-com-gabriel-vasile-mimetype, go-gopkg-in-vansante-go-ffprobe <jgart>`guix pull --news` doesn't tell me what channel those two packages came from <jgart>Ideally I would like to see new/upgraded packages differentiated by channel <jgart>python-foo r-bar go-github-com-alyssa-baz-hacker <asdf-uiop>Good idea! And how about grouping prefixes, too? E.g. emacs: emacs-foo, emacs-bar, etc. Or, better in my opinion, emacs: foo, bar, ... <jgart>maybe like this `2 new packages in Guix Past: python-foo chicken-bar` <florhizome[m]>btw civodul guix still has a performance problem when computing profiles. (The „building profile“ phase stretches very long) <florhizome[m]>It has to do with having (multiple) icon themes in a profile (I fiddled around a bit to find that out. Fonts and gtk themes are ok, though.) <florhizome[m]>Someone opened an issue before Christmas, and said it is gone after c–u–f merge but it is not. You can easily test it by putting two or more icon themes in a profile and installing that. It will not matter if they are already installed somewhere in my experience. <florhizome[m]>For examples breeze–icon–theme and papirus–icon–theme will need a couple minutes in that particular phase for me, that would be outrageous for most sets of two packages. <civodul>jgart: it'd be nice, but that's a bit tricky to do <civodul>florhizome[m]: if you could email bug-guix@gnu.org with a reproducer, that'd be great <civodul>maybe "guix install breeze–icon–theme papirus–icon–theme -p /tmp/test"? <florhizome[m]><jgart> "Ideally I would like to see new..." <- That would be cool. <florhizome[m]>I would also like guix search to give less fields, and so more packages by default (have a „verbose“ switch for seeing all available information on packages), since most of the time you don’t need everything that it displays. I know I could probably alias guix search to include a recsel Filter... I just think it would be a better default. <florhizome[m]>also, when we’re at it, when giving the –K option, I think the message that the build dir was left should be placed a bit more distinguished – after the normal message and maybe with some markup. It’s just hard to find in the bulk of text, but the user specifically asked for that so it should be distinguished in some way or form from the normal process. <asdf-uiop>Is there a command to list the licenses that are defined in guix and their abbreviations? If not: how about adding guix package --list-licenses? <asdf-uiop>I was a bit confused that "mit" wasn't defined when I tried to use it some time ago, and now I have no idea how I should refer to the Apache 2 license. <florhizome[m]>civodul; i retreat. I can’t reproduce it anymore. I could one or two weeks ago, seems like something has happened since then :) never underestimate the gnu crowd <ennoausberlin>Hello. I need some help with configuring elogind. My guix vm is suspended to often (but should never) in /var/log/messages there is a hint, that elogind causes this. How can I prevent this? <florhizome[m]>whooo that means I can finally install all the icon themes I want. No regrets! <civodul>florhizome[m]: heh good :-) if it does happen again eventually, please do report it with a reproducer <abrenon>asdf-uiop: I don't know, that sounds like a need, but on the other hand it's so easily found when working from the guix source code <abrenon>plus it's mainly useful when trying to define packages, so when you're ok with browsing the source <asdf-uiop>Yes, I finally found the source. I have no idea why I didn't before, it seems so obvious and I did look before. <ngz>Hello. I have a question about packages style. Should we systematically replace quote and backquotes with "#~" in arguments field, so it is less confusing? <asdf-uiop>I guess adding the location where the licenses are defined (--> guix/licenses.scm) to the packaging section of the manual and cookbook would make sense, though? I looked there first and only had the idea to look for a function after I didn't find it there. <abrenon>I remember having had the same path, from "where can I find that ?!" to "hmm, guix/licenses.scm, ok, of course" <florhizome[m]><ngz> "Hello. I have a question about..." <- i thought these are g–expressions, and though they work like quote and unquote they still have specific meaning? <ngz>These are indeed G-expressions, but AFAIU they can be a drop-in replacement for backquote and quotes. I saw some recent packages using gexp even though the expression contained no ungexp. Hence my genuine question. <ngz>It may be confusing to use ' ` and #~, so maybe "#~" could stick as "build-side code marker" <florhizome[m]>(I‘m curious why/if it was needed to introduce them, but I think the best you could do rn is explaining them a bit more comprehensible. Since I don’t claim I really understand them, I can’t really make suggestions) <xelxebar>jgart: Oh! I see. That could be nice. I've definitely wanted filters/search on the news output. <florhizome[m]><ngz> "florhizome: See <https://guix...." <- do you mean the reference to g–expressions or is there an example showcasing what you described? <florhizome[m]>btw what speaks against using a gexp without ungexp–ing ? You only need to ungexp if you want to reference something in your normal space right? <ngz>If you use gexp without ungexp, one may argue that plain quote is sufficient, much like `let' vs `let*' where you don't use the latter if you're not taking advantage of the benefits it provides. OTOH, using a single markup has pros to. <ngz>jgart: you sure were ;) *jgart never thought changing let* to let could be so expensive <abrenon>asdf-uiop: on the other hand, there's a relatively direct path to (guix licenses) from the packaging section <abrenon>if one is curious about licenses, it seems natural to read the "Software Freedom" in the Packaging Guidelines <abrenon>that leads quite naturally to "Defining Packages" <xelxebar>florhizome[m]: "recsel" Whoa. Just learning about this. Super cool! <abrenon>which in turn contains a link to the "package reference" <abrenon>where (guix licenses) is stated explicitely <abrenon>it may be a bit long, but I wonder where else it could be put. Maybe on the 16.4.1 Software Freedom page directly ? <civodul>abrenon: mentioning (guix licenses) right there sounds like a good idea <g_bor>I have just run the testsuit on my new shiny install <g_bor>guix-git-authenticate failed with <g_bor>cannot locate remote-tracking branch keyring <g_bor>and guix home failed because of the XDG_DIR no available <abrenon>asdf-uiop: do you want to do it since the idea came from you ? or would you rather have me doing it ? (let's not work both on the same stuff) <g_bor>do you think it would make sense to make these tests conditional? <ngz>florhizome[m]: See for example recenc dc64e7a1ac53d56675cc28135f11ec38a1de4c23 <civodul>g_bor: hi! re tests/guix-git-authenticate.sh, it means that you lack a local "keyring" branch <civodul>for the Guix Home failure, can you give more details (which test fails and how)? <jgart>sneek: later tell raghavgururajan Yooooo guix homie are you coming to the guix docs meetup on Saturday? <florhizome[m]><ngz> "If you use gexp without ungexp..." <- But here you are assuming gexp does exactly the same as quote? <g_bor>civodul: yup, the keyring... <g_bor>for the guix home we tracked the thing down laready. <g_bor>the problem is that it depended on elogind. <g_bor>If run on a system without it it fails <g_bor>the requirement is documented in the manual <g_bor>but I don't think there is a bug particularly for this <g_bor>civodul: I don't really know what we should do with the home test... <g_bor>It could be skipped failing the directory check... <g_bor>or it could ensure the existence of XDG_CONFIG_DIR for the duration of the test for a 'fake user' <civodul>g_bor: it would be great if you could send the details to bug-guix <florhizome[m]>There was a patch series with seatd and greetd services by muradm g_bor to be able to start a session with seatd, I think it addressed the problem of XDG_RUNTIME_DIR <civodul>ok but i don't know what "the problem" is <florhizome[m]>civodul: the reference in the man is a note at the end of 11.1 <jgart>where can I find the code for the sneek bot? <brkwnds>Does Guix always keep all the package objects in memory, or does it somehow load them only when it needs to do stuff like building/installing/searching etc.? <florhizome[m]>Is .pre-inst-env still a thing? I just git cloned the guix repo to make a commit but it's not in the base dir <civodul>brkwnds: it loads them when needed and then keeps them in memory <civodul>there are exceptions though, notably 'guix shell' now caches things in a way that allows it to skip package loading altogether <jgart>florhizome[m], this is what I do on my wretched foreign distro: `guix shell --container -N coreutils vis ripgrep skim -D guix --share=/var/guix/` <jgart>florhizome[m], ./pre-inst-env guix foo <jgart>`./pre-inst-env guix build python-sucks` <rekado_>florhizome[m]: it is generated. You’ll need to ‘./bootstrap && ./configure --localstatedir=/var && make -j’ first <asdf-uiop>abrenon: I haven't contributed anything yet, so I haven't absorbed the right way to do it. I copied a few messages from rekado outlining the process to another newcomer the other day, but I want to finish a few packages before having a closer look at them. I can have a go at the documentation of the licenses after that or you can do it. I'm fine with either. <ngz>rekado_: I tested mumi API, it has issues retrieving patches when there's a 0/N front letter, or a 1/N without a patch. IMO it should ignore mails without patch so "| git am" part does not barf. <abrenon>jgart: thanks for the link ! I remembered there was something like that but I hadn't saved the date, I'd love to attend (plus I don't have the time to submit anything today so ^^) <zimoun>apteryx: in your quest about Rust, have you tried to package gccrs? <roptat>after two years of not using a computer, I forgot the passphrase to the root fs... <sneek>Welcome back roptat, you have 1 message! <roptat>so I'm trying the installer now ^^' <roptat>if it's been two years and I haven't missed it, there mustn't be anything important in there anyway <roptat>I figured 1.3.0 is a bit too old and I'll get in trouble when pulling <roptat>I was looking forward to the fun of upgrading the system after two years, but since I'm reinstalling anyway... <bost>Hi. What package should I install when I want to use gpg? <bost>in particular the command `gpg -d somekeyfile.pgp 2>/dev/null` <bost>for setting environment variables <g_bor>I have just encountered something stange <g_bor>when I type in issues.guix.gnu.org I get a page missing, but when I refresh it works <dcunit3d>can `guix pack` produce an OCI image or something that can become an LXC container? <roptat>it can do docker, but I don't think that's the same as OCI? <rekado_>ngz: would like to send a patch to fix this? Seems like a pretty straight-forward fix. <g_bor>roptat: I assume docker build containers that are OCI <dcunit3d>singpolyma roptat what kind of image do i need in order to convert it into an LXC? <roptat>sorry I'm not the right person to ask, I don't do containers <roptat>it didn't seem plausible, but I was pointing out that maybe the docker containers were OCI <singpolyma>dcunit3d: what do you actually need? Are you running containers or vms on the system that has guix, or exporting to an LXC-based host that has no guix? <dcunit3d>i see, i'm new to virtualization and esp. LXC. i'm trying to run a lightweight guix on proxmox as a container instead of a VM <rekado_>but I don’t know if the resulting image *actually* is valid according to the OCI specs. <dcunit3d>singpolyma: i'm exporting to proxmox, where i want to run guix containers/vm's <singpolyma>dcunit3d: so you want to run a full guix system inside a container in a host that is not guix aware, yes? <rekado_>IIRC when I first started on the docker backend for ‘guix pack’ there had been no OCI spec (or docker had not adopted it). <g_bor>it looks like that there is lxc-create -t oci which should work with what we output as docker format <singpolyma>So you want guix system command to bae a docker container and you can try it, if it doesn't work then that's good for us to know <g_bor>the OCI spec was actually created from the docker spec <dcunit3d>thanks rekado_. i found the source for `guix pack`, but i'm trying to compare it to the OCI spec and ecosystem. most docs that i've looked at so far don't discuss building the images <dcunit3d>thanks g_bor singpolyma, i'll try that and let you know <rekado_>dcunit3d: the docker image generation part lives in (guix docker). <AndrewYu>``As of version 1.3.0, the standalone Guix System can be installed on an i686, x86_64, ARMv7, or AArch64 machine.''---How do I get it for aarch64? I installed the package manager, but I want the whole system (with Linux-Libre) <AndrewYu>(Raspberry Pi 4, doesn't care about WiFi, cares about usable HDMI monitors) <AndrewYu>The bootloader would be a problem, testing with RPi UEFI <apteryx>AndrewYu: not a Pi tinkerer, but last time I checked it needed a proprietary GPU driver just to boot (hopefully that info is outdated). <civodul>AndrewYu: currently we don't provide ready-to-use installation images for Guix System, mostly because there's no standard way to boot these machines <civodul>so we'd have to provide one image per "device family" <civodul>you can see there definitions for specific devices in (gnu system install) though <zimoun>apteryx: in your quest about Rust & co., have you tried to package gccrs? I am asking to know if an attempt had already been tried, or not at all. :-) <apteryx>but that's just based on reading their status updates, not actually trying to use it <zimoun>apteryx: thanks. It is just because I recently read something and give a llot at the instructions https://github.com/Rust-GCC/gccrs and it appears to me to be worth to have this “experimental” package. :-) <apteryx>zimoun: if you have time to package it it'd be a much welcome addition! <KarlJoad>I am planning on switching my VPS website to Guix tonight/tomorrow. I already have a small config set up. Is there something else I should consider before doing this? <civodul>zimoun, apteryx: maybe roptat can shed some light on the ocaml failures? <Guest44>I am not able to build the `password-store` package and it seems that the problem is with it testing for unicode support. Does anyone know how I can resolve this? https://dpaste.com/3E5HNFC3B <jpoiret>civodul: re what you said on the ML about (guix self), when running installer tests it's the current checkout's installer-program that's used, right? <zimoun>civodul, apteryx: yes for sure roptat can shed some light on the ocaml failires. :-) I guess, the reason is timeout of ocaml-boot to bootstrap ocaml4.07. That’s a common error, I guess. <Guest44>It seems that my system doesn't have support for unicode but I can't figure out what I need to install. <jpoiret>Guest44: it's not an issue with your system, guix builds don't depend on the state of your system <AndrewYu>There was a hacky UEFI way to boot OpenBSD on there <Guest44>jpoiret: do you reccommed something that I should do? <jpoiret>Guest44: i think it might be missing grep as an input <g_bor>I am suer I am doing something stupid, but I just can't find out where things go wrong... <g_bor>I have written a package definition, which does a git fetch from a local repo <Guest44>Should I modify the file `$HOME/.config/guix/current/share/guile/site/3.0/gnu/packages/password-utils.scm` and add grep as an input? <jpoiret>Guest44: no, you won't be able to modify that, as it links into the store (which is read only) <g_bor>it seems to be working, as I get a different error if I break the commit hash <g_bor>but if I give a commit hash I still get an error... <roptat>civodul, apteryx: "timed out after 3600 seconds of silence" is there a way to increase that timeout? it's expected to be silent for a long time <g_bor>it is error: upload-pack: not our ref followed by the hash <roptat>the max-silent-time property doesn't seem to be used <Guest44>so people that contribute to guix use the latest version and then are able to easily push their changes to master <g_bor>I have never actually tried this before (i.e. build a package from a git repo living in a local directory), but this should work, no? <jpoiret>well, everyone runs the latest version, just that some people checkout the source locally to work on it <jpoiret>when you `guix pull` you get the latest and greatest straight from git <g_bor>I also tried to modify it to an absolute path, but it then tells me that it could not read from the remote repository... <jpoiret>it's just that it doesn't come in an easy-to-tinker-on way <jpoiret>g_bor: are you using git-fetch? I remember someone trying to use git-fetch with a local repo and it not working recently, but I might be wrong <jpoiret>the thing is that git-fetch internally uses guile-libgit2 rather than command-line git, so things might work differently <podiki[m]>why wouldn't a native-search-paths work? I've added it to a package but don't see it reflected in the profile (and changing it doesn't seem to cause rebuilds) <Guest44>ok thanks. I followed the instructions from your link to get a local checkout. Ill start reading the rest of the devolper manual. <jpoiret>podiki[m]: what package did you add it to? Search paths are added only when the packages are installed in the profile, and not as dependencies <g_bor>lemme check how is it done... <jpoiret>ie if I want guile-newt in my guix shell, i use `guix shell guile guile-newt`, because just `guile-newt` wouldn't add the search path <podiki[m]>jpoiret: I was installing the package directly, this is for a package I have locally and added it to the definiton <civodul>roptat: re max-silent-time, you're referring to which package? <podiki[m]>when I do it for something like rofi, it also only seems to take if it points to something that the package contains? (still figuring it out) <civodul>roptat: ISTR that Cuirass now honors the property, but i'm not sure <g_bor>civodul: the failing home test thing got issue number #53253 <jpoiret>podiki[m]: yes, a search path is basically a spec saying "ok, for all of my dependencies, look into this specific directory and add it to the env var" <podiki[m]>ok, so a package has a native-search-path and the profile needs to have that and something with that package as input? <jpoiret>i think the best example of a search path would be GUILE_LOAD_PATH. guile declares the native-search-path for the subdir /share/guile/site/3.0, and it will therefore look into each package that has it as an input and add that directory to the env variable <jpoiret>although when making a profile you only need to add the profile's subdir itself <g_bor>civodul: fine, I will do that... <jpoiret>civodul: I'm trying to run `make check-system TESTS="gui-installed-os"` (after a make clean) and I'm getting an error while building a guix derivation <g_bor>civodul: how should I share the content? <jpoiret>and sure enough, (mkstemp! "test/somethingXXXXXX") doesn't work if "test/" doesn't already exist. <civodul>g_bor: ah sorry, so the content of that directory won't be all that useful <rekado_>progress on the aarch64 nodes is blocked by failing Guix tests <podiki[m]>jpoiret: thanks, makes more sense now (I was trying things without installing the dependent) <podiki[m]>so to answer my earlier rofi plugin question, I'll add the native-search-path to rofi and then my plugin package will work correctly (in the same profile); easy! <rekado_>I fixed one test failure on non-x86_64, but updating the “guix” package failed due to another test failure. <g_bor>the 1.3.0 installer generated config triggers a deprecation warning on target <rekado_>haven’t been able to investigate more <jpoiret>g_bor: that's normal, many things have changed since 1.3 <g_bor>I also assume if I make a new installer now it will be gone. <g_bor>I will modify the installer anyway, as it turns out that guix home actually depends on elogind, it would be nice to give an easy way to install it <g_bor>I will also see the deprecation warnings then... <jpoiret>if you select any desktop environment, you will have elogind along with it <jpoiret>and i'd say `guix home` is advanced enough that users will be able to also add elogind to their own system configuration if they require it? <g_bor>jpoiret: I am aware of that, but I mostly work in an environment where I don't have that... <g_bor>elgoind is one of the services I find myself manually adding and dbus is another... <civodul>g_bor: where does that elogind claim come from? the build environment when we run "guix build guix" certainly doesn't have elogind <jpoiret>yes, but would you really want to present an option to individually add services like dbus/elogind/etc... in the graphical installer? you always have the option of installing manually, or even just editing the generated config file at the end of the graphical installation <g_bor>the actual requirement is t have XDG_RUNTIME_DIR properly configured. <civodul>i believe XDG_RUNTIME_DIR is unset in the build environment tho <jpoiret>oh but in a build env, XDG_RUNTIME_DIR won't exist anyway (you can create it manually in the package def if you want) <jpoiret>i think they're simply talking about using `guix home` on a fresh install <g_bor>actually it is in the latest version of the manual <g_bor>I just did a system reconfigure with elogind, and running the testsuite afresh to check if it really solves it... <civodul>oh, i thought we were talking about tests/guix-home.sh <g_bor>it is actually failing on me exactly the same way as it is failing on the command line <g_bor>civodul: it might also be something completely new... <g_bor>If elogind does not help, I will try to debug it <jpoiret>what do you mean by "running the test suite"? <g_bor>so I am running a make check in a guix checkout <g_bor>the exact error is in the issue <djeis>If a one-shot herd service depends on some other herd service and that other herd service is restarted, will the one-shot service be restarted too? <civodul>damn it, i had left diffoscope run in a shell buffer and Emacs went mad trying to font-lock the damn thing <podiki[m]>sneek: later tell apteryx were you able to get the password-store tests passing once you found the tree problem? <jpoiret>isn't the test failing because grep is missing? <podiki[m]>jpoiret: password-store? a new failure? the previous one was on the emoji test, which turned out to be new tree version output <apteryx>podiki[m]: there's a patch on guix-patches <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, podiki[m] says: were you able to get the password-store tests passing once you found the tree problem? <podiki[m]>I wonder if this is why other distros are still on tree v1 that are normally fast to update, like arch <podiki[m]>anyway, thanks all for tracking down and patching that one <KarlJoad>I an trying to convert an Ubuntu system to Guix System. I think I am missing a config file for network access for CI servers. Namely, I get Servname not supported for ai_socktype. Anyone have an idea? <jpoiret>podiki[m]: oh my bad, I only had a cursory look earlier when someone else asked about it <Tirifto>Hello! Is ‘guix upgrade --dry-run’ ever supposed to change one’s configuration? <mbakke>oh, 'password-store' is failing for quite some time; I should add error reporting to my profile update loop :P <mbakke>Tirifto: '--dry-run' should never change anything, but may need to download or build things to do its work <unmatched-paren>my laptop does this weird thing where it suddenly stops recognizing the boot device, and i think reinstalling grub will fix it <Tirifto>mbakke: Thank you. I think I may have found a bug in that case: when I run ‘guix package --rollback’, it rolls back my profile, and when I run ‘guix upgrade --dry-run’, it changes my profile to the newer version again. I’ll submit a bug report unless I missed something. <unmatched-paren>but /run/{current,booted}-system isn't there in the chroot, so there's nothing in the $PATH <unmatched-paren>i'm trying to find things in the store, but i can't run find on it, because it's also in the store :) i'm not sure how performant that would be, either <mbakke>Tirifto: that's definitively not supposed to happen, thanks for reporting it :-) <mbakke>unmatched-paren: see the "system" links in /var/guix/profiles <Tirifto>mbakke: Any info that’s generally useful to report, other than host system and Guix version? <mbakke>Tirifto: just the steps to reproduce and your 'guix describe' should be fine :-) <unmatched-paren>ok, so running guix reconfigure says the connection to the guixd socket was rejected. is there a herd service that i can start? <unmatched-paren>i guess i'll basically need to recreate the guix boot process from scratch <unmatched-paren>(i've got the whole chroot with procfs, sysfs, runfs, efivars etc mounted) <Tirifto>mbakke: Sent the report off; thank you for the confirmation! :-) <rekado_>after the release we should have a little shepherd hackathon <florhizome[m]>Search paths might be relevant to every program that would need to access code installed under that path though, so in general we set search paths exactly for producers, right? a search path is exactly not a wrapper, it exposes paths in the store directory of a package to the shell (?), while wrappers expose paths in the store directly to specific programs. So search paths apply whenever you need to expose paths between packages that might <florhizome[m]>not have a direct relation. Here, TERMINFO_DIRS is relevant to all programs that might be started inside a terminal, since they need to access the terminals terminfo file, not only the terminal itself. <florhizome[m]>What I’m not getting though, is why we‘re using native–search–paths here –– I thought they were build–time only, relevant again mostly for cross–compilation. <unmatched-paren>grub.cfg looks to be autogenerated and intact, so i don't see why not, but i don't want to risk messing stuff up even more <podiki[m]>florhizome: also learned more about search-paths yesterday and today; I'm not sure the distinction with native or not (mostly see native, or set the same for both?) <mbakke>florhizome: native-search-paths is for "host-side" search paths, i.e. code to be executed on the currently running machine and not the (cross) target system, just like native-inputs vs inputs <mbakke>the distinction only matters when cross-compiling <podiki[m]>mbakke: so if the search-path is not used for compiling (only e.g. runtime loading of plugins or something) then there is no difference? <lilyp>only native-search-paths are used when not cross-compiling something <podiki[m]>so if there is no compile/cross compiling difference for package (it is only when running), just native-search-paths? or should both be set? <jgart>is there a cli flag for `GUIX_PACKAGE_PATH=`? <jgart>`-L .` does not seem to be the same thing <jgart>is there an interest in adding one? <lfam>Sounds like you are interested :) <lfam>It's kind of a deprecated interface, although I think it's really useful and orthogonal to channels <civodul>jgart: -L more or less does the same as GUIX_PACKAGE_PATH <lfam>What's nice about it is that turning it on and off is really cheap <jgart>do channels provide a similar convenience experience when working from a local channel checkout? <jgart>I should use file:/// in channels.scm? <jgart>civodul, I just tested -L and it does not work the same <jgart>under `Generating channel package data` <podiki[m]>jgart: yes you can use a local channel in channels with file:, but you'll still need to commit and do a pull for changes <jgart>podiki[m], yup but that is not as convenient as just adding a flag to a cli command <kaelyn>jgart: I've used a bare path path as the URL to a local git repo before for a local channel <jgart>podiki[m], that approach involves more steps <jgart>I'd like to just clone a channel and "put a flag on it" <lfam>Overall, both GUIX_PACKAGE_PATH and --load-path are features for advanced users, IMO, compared to channels <jgart>I don't want to open a file, edit the file, save it, pull, etc... <jgart>I just want to add a path to a cli flag <podiki[m]>jgart: yes, it is slower, so not quite the same in practice of using (agree) <lfam>--load-path works just fine on my GUIX_PACKAGE_PATH tree <lfam>So, I'm not sure why it doesn't work right for you <jgart>not sure what you mean by those commands being a feature for advanced users... <jgart>you mean people hacking on a checkout? <lfam>Basically, what I mean is that Channels are what you *should* use. These other methods of adding packages pre-date channels and lose some important properties given by channels, such as authentication and provenance <lfam>So, if one understands the pros and cons, they are fine to use. But, we don't recommend them as the primary way to add packages <jgart>well, just food for thought. It'd be nice to have something like a `--add-local-channel=`. It should probably be called something more general <lfam>And, if --load-path isn't working for you, we could find out why <civodul>-L is what you need when you are working on a channel <podiki[m]>channels to me at least, seem like what you want for more regular "usage", but if you are hacking at packages and such it can be easier to use -L <lfam>Right. `guix pull` with channels is a little slow for hacking <podiki[m]>if anyone wants to take a quick look before I submit, think it is pretty straightforward at least <jgart>so how should I do this instead? `GUIX_PACKAGE_PATH=../guixrus guile guixrus.scm | jq` <lfam>What... is that supposed to do? :) <lfam>Come on, help us help you. Just explain your goal <lfam>Is it supposed to print a list of packages in JSON format? <lfam>So, it's shows the list of packages in guixrus that are not in GNU Guix? <jgart>it prints json of package data from that channel <jgart>yes, it shows the list of packages in guixrus <singpolyma>jgart: i think you want guix repl -Lplace guixrs.scm <jgart>and this one gemini://whereiseveryone.srht.site/ <jgart>singpolyma, thnx I tried that before but it failed iirc <singpolyma>Guest21: no. In guix almost nothing is done as root <jgart>singpolyma, I'm able to do this `GUIX_PACKAGE_PATH=../guixrus guix repl -Lplace guixrus.scm` <jgart>but that is equivalent to `GUIX_PACKAGE_PATH=../guixrus guile guixrus.scm` <ryanprior[m]>The only version of Python in Guix is 3.9, but 3.8 and 3.7 are still supported versions. Suppose there would be any objection to adding packages for them? It would be convenient for me to express a specific Python version. <lfam>Yes, we could add them ryanprior[m]. As long as it's understood that they'll be removed swiftly when they are no longer supported <jgart>well it doesn't fail but it returns an empty list <jgart>ryanprior[m], See the "Python Past" channel <lfam>Something that's been on my mind is adding a package property such as "end-of-life-date" so that `guix lint` will complain when something is abandoned upstream <ryanprior[m]>I'd rather not use a channel for a python that's not "past" - python 3.7 is still a current supported version for another year and a half. <jgart>singpolyma, I get `{"packages":[]}` <singpolyma>lfam: lots of "abandoned" stuff is still very useful, though <lfam>That's true singpolyma, but Guix is a distro, not a place where old software goes to die <lfam>There is the guix-past channel for that <lfam>And we don't just remove anything because it's EOL. See Python 2. We do understand the context <jgart>singpolyma, this? `guix repl -L guixrus guixrus-website/guixrus.scm` <singpolyma>lfam: but given the nature of guix having defs for "old stuff" only helps not hurts <ryanprior[m]>I tried web searching "guix python past channel" and not seeing anything relevant either o.o <lfam>singpolyma: I disagree, as somebody who has put effort into long-term maintenance of the distro. <lfam>singpolyma: When you have abandoned, increasingly insecure programs in the distro, people add packages that depend on them, and in the long run the social situation around removing these things only becomes more difficult' <singpolyma>lfam: but you don't have to mantain a def for a specific versions right? It can never change anyway <lfam>I'm not sure what you mean <jgart>singpolyma, re: just -L: what dir am I in when doing that? <singpolyma>Like, you should never have to edit a package def if that def is for a specific version <lfam>singpolyma: Okay, but I don't see how that is relevant to the discussion <singpolyma>jgart: whatever your repo root is. The .. from where your script is <lfam>Additionally, it's not true to something like python-2.4 would not require effort. It has dependencies too, and they will be updated, eventually breaking it. <singpolyma>lfam: oh, if you have it using inputs that themselves get edited, yeah <lfam>Overall, it's a question about "What is Guix?" Guix is a lot of things, but I don't think it should be a place that keeps old programs alive. It should be a living distro that keeps moving <ryanprior[m]>singpolyma: old stuff is still reachable via `time-machine`, and we should find ways of making old deprecated packages accessible. But I think the main branch should exclude unmaintained legacy stuff from the default package search & archive even if it's useful. <lfam>Already, Guix keeps old programs around for longer than most other major distros <ryanprior[m]>guix-past doesn't have python3-anything, it only has old deprecated versions of python2 <lfam>We have a very generous deprecation timeline <jgart>ryanprior[m], maybe a new channel is needed then or extending Guix Past? <lfam>guix-past accepts contributions... <singpolyma>jgart: ok, last two tries from me, try from the folder where the package def module is, -L again. Other thing I have needed (never for repl, but for some commands) is -L$PWD instead <ryanprior[m]>they are in support, people are using them in production and upstream considers that legit <lfam>Anyways, I'm not talking about python 3.7 and 3.8 <jgart>ryanprior[m], Maybe talk to Guix Past and tell them what you want to do <lfam>If you want to do the work, it will be accepted <ryanprior[m]>in Ruby we keep all current versions in Guix - we currently have 2.4 through 3.0.2 packaged <lfam>It will also not be focused on by many contributors, unless it grows a use case. So you'll need to be ready to care for these packages <jgart>singpolyma, can you share the command I should run? <lfam>Fedora already removed Python 2, for example. And Debian will remove it in the next release <lfam>Guix is one of the most accomodating distros for abandoned programs <ryanprior[m]>I agree that an end-of-life date in the package definition would be useful data <lfam>I actually first considered the subject in regards to a piece of code, not a package <jgart>singpolyma, that also gets `{"packages":[]}` <jgart>singpolyma, anyways what I put in the website README now *works* <lfam>ryanprior[m]: I do advise you to not write these Python packages using inheritance. Instead, make them standalone package definitions. It will make long-term maintenance a lot easier for you <jgart>so I'll just continue doing that until I get enlightened <lfam>And, it will ease maintenance of the current Python packages <singpolyma>jgart: ok, well, I would need to look at your code a lot more to see what is wrong. Sorry. I use guix repl -L. a lot but obviously my code is somehow different <ryanprior[m]>In ruby we do it using inheritance, should we be changing it there too? lfam <lfam>No, don't change it. But please don't add new inherited packages for Python compilers. It makes it *very hard* to understand how each package is actually defined, which makes it super hard to update them <lfam>And it would be a pity to make it harder to maintain the current Python package just to save a few keystrokes while re-defining some old versions <jgart>lfam, re: Instead, make them standalone package definitions. : that's good advice <lfam>Like, we don't want to have to consider the effect on python-3.7 when working on the current Python <florhizome[m]><lfam> "It's kind of a deprecated..." <- I think we need a local configuration path first. more finegrained behavior which modules are used when. <florhizome[m]>In general I don’t want every guile snippet I write to be loaded directly into the packages and services I manage, which causes spontaneous breakage. I would like to control what I load locally by record–type – services, packages as well as by path and I think it’s good to have a general „guix config path“ (and in there a manifests path). Pretty much like emacs. ig, right now what guix does in my home dir is pretty all over the <florhizome[m]>Also when building from a file I would like to choose the package I want to build from it, bc I don’t want to put every file I work with a bit more into a path with other files. <porcupirate>`guix home build ...` "builder for `/gnu/store/1rq88655navr6vhadif8sjskk31m08r5-gdk-pixbuf-loaders-cache-file.drv' failed due to signal 11 (Segmentation fault)" <singpolyma>I will try to remember to look when at a real computer :) <ngz>Speaking of abandoned packages, we have (at least) one package without upstream: toutenclic. It now solely exists as a derivation. What can be done about it besides removing it? =/ <lfam>ngz: I think the answer is less clear for end-user applications. Mainly, I am concerned about abandoned libraries and compilers <lfam>ngz: Is there even a place from which to download toutenclic's source? <ngz>lfam: Not anymore, AFAICT <lfam>Does anyone have a copy of it? We could put it on archive.org <lfam>Or else, it will eventually stop building, and we will have to remove the package <ngz>It is still possible to do guix build -S toutenclic since bordeaux still has the derivation. *rekado_ is still confused about this guirus/whereiseveryone thing and the amount of … promotion that is done here and on the mailing list <lfam>Well, it's not really being promoted at the moment. It's just being discussed <florhizome[m]><podiki[m]> "florhizome: also learned more..." <- I asked about search paths when packaging wayfire and, what shall I say, most ppl seem to be confused about it. But it’s really important to get more complex programs to work I think. <florhizome[m]><mbakke> "florhizome: native-search-..." <- oh, so it’s kinda the other way around in the end as inputs... <lfam>I think it's okay, rekado_, as long as it follows the FSDG. I don't think there's any debate that the patch review process is a little too slow for some people. And this provides a place to capture their work <ngz>lfam: so how could I (or someone else) put the result of "guix build -S toutenclic" on archive.org? <rekado_>yeah, I’m just unusually irritated for some reason. Sorry. <lfam>ngz: There's an "upload" button on the upper-right area of archive.org <florhizome[m]>I think debating if a channel is ok or not is kinda a bad approach. if you don’t want channels, and don’t want ppl to talk about them using them, delete the functionality. <lfam>I think we should drop it. We all get irritated from time to time <lfam>I can certainly relate to that <ngz>I don't have an account there. Bah. <unmatched-paren>ftr, i managed to fix my issue by invoking /gnu/store/...grub-efi.../sbin/grub-install --bootloader-id=Guix :) <lfam>ngz: I can upload it if you want <ngz>lfam: If you don't mind, yes, I would appreciate it. <lfam>So, that's the long-term solution <lfam>I was able to get it from CI <jgart>rekado_, guixrus is a guix project just like haunt is a guile project. The discussion place for haunt is on #guile. Why is discussing guixrus on #guix worrisome or confusing? <jgart>guixrus is about to send a huge batch of patches to upstream for review. Recent packages that were in guixrus chanel just got merged by Nicolas Goaziou a few minutes ago into upstream and removed from the guixrus channel. <jgart>We are using the channel as a tool for onboarding new users to contributing to upstream. We have good intentions for GNU Guix if that is not clear. We are friends to the Guix community. <lfam>I understand the reservations about the project, but mainly because it highlights a problem with GNU Guix's contribution process. <lfam>So it can be a bit painful to accept <jgart>It shouldn't be seen that way <ngz>lfam: Do I need to change the source field in the package definition or will it be transparent? <lfam>But, it's a good thing, like I said earlier <lfam>ngz: You'll need to add the archive.org link to the package definition <ngz>lfam: OK. uri can be a list of URI, so I can add the archive.org link (which is?) instead of replacing the old URI, in case upstream resurrects one day. <lfam>jgart: Well, we'd prefer if everything related to Guix happened within our infrastructure. But, the project is too big for that to happen reliably, and we made Guix so that it could easily deal with 3rd party repos <jgart>lfam, Next Guix Packaging Meetup (Jan 23) we are going to send a ton of acceptable patches from guixrus channel to upstream for review. <lfam>So, it's just a case of Guix being used as designed :) <lfam>ngz: Regarding the URL... patience :) <florhizome[m]><lfam> "I understand the reservations..." <- You can see it as a problem or not, but ppl find their solutions in each case (; <lfam>I said it was a problem with GNU Guix's contribution workflow. Not with the channel <lfam>I even praised the channel <lfam>And I've done so several times <jgart>We *are* using GNU Guix's contribution workflow. We are just a pipeline to it. <jgart>We prepare patches in guixrus and then send them over <lfam>I feel like people are trying to argue with me over a point I did not make <jgart>It is more convenient for us <lfam>Let's just drop it. I don't know how many times I can say that I think the channel is a good thing <ngz>lfam: Thank you very much for the URL, I'm going to add it to the package definition ASAP. <jgart>anyways, hopefully over time it will be clear that we are only trying to benefit and help the community and stimulate development for Guix. <lfam>After samplet's work at SWH is done, we can go through the distro and remove all the archive.org links <jgart>I'm thinking of giving a lightning talk at Guix Days to clarify and introduce motivations for guixrus. Unless that would not be welcome...? <lfam>I think it's a really good thing that channels are proliferating <jgart>I'll send an application, then <lfam>It shows how much Guix has grown <jgart>lfam, I don't know if I'd say that much :) It's still a pretty niche thing ha <jgart>but yeah, relatively speaking <Guest21>If not I don't understand how it is being installed <lfam>It's not being installed Guest21 <Guest21>just built? So after I build it how do I use it? <Guest21>I should say that I am doing this because I want to fix a broken package. I am just having trouble understanding how I will eventually submit my patch. <lfam>What CPU architecture are you using Guest21? That is, 64-bit Intel compatible (x86_64 / amd64)? 32-bit Intel? 64-bit ARM? <lfam>Oh Guest21. That's a different story <lfam>Your original question is not relevant to that goal, but I'll answer it now. I don't know if this is considered the best way, but I would use `make guix-binary.x86_64-linux.tar.xz` and then install according to the Binary Installation section of the manual <lfam>However, for fixing a package and testing your fix, we use the workflow describing in the manual chapter Contributing. Specifically the sections Building from Git and Running Guix Before It Is Installed <lfam>So, now that you have run `make`, you can skip to the "Running Guix Before ..." part <lfam>You will be able to do `./pre-inst-env guix build foo`, in order to test the change to foo package <lfam>That's how we develop and contribute to Guix <char>Hello. Is anyone familiar with cmake? I have this issue: it tells me "wxWidgets wx/version.h file not found in <many colon sepearated paths>" one of the paths include wx/version.h nested a few levels. <lfam>Guest21: This 'pre-inst-env' script makes Guix use the copy of Guix that you've built in your Git checkout <lfam>So, basically, it lets you use your modified Guix <Guest21>ok now I understand. I thought I was missing something obvious about having to install it. <lfam>Let us know if you need more help <char>btw I think this is realted to guix because if i use guix shell -D, I can build just fine manually. <eonn>Hey everyone, what is the 'right' way to patch a program provided by a package? I have st installed, but I would like to modify a header file and apply a diff. Should I write a package for my own version of st, or can I forego the substitute on the mainstream package and somehow apply a patch pre-build? <civodul>eonn: there's the --with-patch package transformation option that can help <eonn>I see. This looks like what I've been searching for. I'll read the manual and give it a try. <lfam>char: So, it looks for the header file but not in the right place? <char>It looks to me that it is looking in the correct place. in the path list is /gnu/store/---wxwidgets-3.0.5.1/ which has include/wx-3.0/wx/version.h in it <lfam>I doubt it expects the "wx-3.0" component of the path <char>That did cross my mind, but I would think it is just searching for <anything>/wx/version.h since that is what it said. <lfam>It's looking for "<anything>/wx/version.h"? <eonn>civodul: That was easier than I thought it was going to be. Thank you. I do have st defined as a package in /etc/config.scm under operating-system->packages. Can I specify this option or should I just remove it? <eonn>'this option' being pointing the build source to be some file <char>lfam, it said "wxWidgets wx/version.h file not found in ..." not include/wx/version.h <lfam>This is a case where being explicit is useful, char <lfam>I can't really tell what you are trying to say <civodul>eonn: if you keep it in config.scm, you'll have to add a snippet equivalent to --with-patch to transform it <char>lfam, I agree. we are on the same page. I'm just not really understanding the cmake errors. <lfam>Anyways, I still think it doesn't expect the "wx-3.0" component of the path <lfam>Or rather, it doesn't expect two levels of directories between "include" and "version.h" <char>lfam, assuming the wxwidgets is correct. I should configure cmake to expect two levels? <lfam>I really don't know the best way to fix this. If it were me I'd just find a way to make it work <eonn>civodul: Awesome. It's cool how fine-tuned you're able to define your system under GuixSD <char>lfam, the issue is that I'm not very familiar with cmake. <lfam>I'm sure that somebody can assist! <podiki[m]>eonn: also cool: if you do guix install with some transformation and later export your packages as a manifest, the manifest will apply those transformations (it will export the code to do that)