<iskarian>...or has that been superseded by kernel-module-loader-service-type? <jackhill>Hi, how do I specify a non-default make rule for the build phase of the gnu-build-system? <bavier[m]>There's a #:make-target argument, or can always modify-phases. <nckx>jackhill: (modify-phases %standard-phases (replace 'build (lambda* (#:key make-flags parallel-build? #:allow-other-keys) (invoke "make" "-j" (if parallel-build? (number->string (parallel-job-count)) "1") "THE_TARGET"))) <nckx>bavier[m]: #:make-target? <jackhill>I don't think there is a #:make-target. I, too, was wishing ofr it :) ***hitchcock.freenode.net sets mode: +o ChanServ
<ds-ac_>Hi there. I am new to guix and am trying to get used to the system architecture, but have a problem: when trying to exefcute a binary present in a directory, it keeps printing "no such file" error. It there a way to execute this binary ? <pkill9>ds-ac_: by default, guix doesn't support binaries designed for downloading and running from directory <ds-ac_>So should I wrap it in a package I install with required inputs ? <roptat>ds-ac_, "no such file or directory" here means that the binary file you're trying to executes wants to use the linker from /lib or /usr/lib, that doesn't exist on Guix System (you can check: no /lib). There a few ways to work around that <roptat>you can create a package that builds that thing from source, that way it gets linked with the proper location. If you are lazy, you can use patchelf to set that location by modifying the binary (and probably rpath because it won't find its libraries), or you can reconfigure your system in such a way that it provides a /lib, etc <apteryx>civodul: hi! Yes I can stop rebasing version-1.3.0; let's just drop the WIP commit at the top (I'll expound it locally) <ds-ac_>roptat: thank you, I will look into this :) <apteryx>I'll test the guix-install.sh change I made to make sure it works too <vagrantc>oh, version-1.3.0 has been getting rebased? <emestee>apteryx: hey if you're running the test suites, check if you get a guile crash in dmesg <apteryx>vagrantc: yes, was a couple times (well, for savannah rebased = branch deleted and recreated) <vagrantc>ah, i've been doing buidls of the debian package from that branch <vagrantc>but who knows which commit history it has :) <vagrantc>heh. yup, based on some rebased history, apparently *vagrantc made a local tag v1.3.0rc0 :) <PotentialUser-34>Hi all, I just went through the installer and the initial downloads are taking very long; not due to network speed but because of a short pause after each download. I was wondering if this is how it will be when the system is live and I'm running updates? If so, is there a way to parallelize downloads? <lfam>PotentialUser-34: That problem has been fixed in more recent versions of Guix than the one included in the installer <lfam>So, after you finish installing, your first update will fix it <vagrantc>you can configure guix-daemon to use --max-jobs=N ... which helps with that scenario a bit ... but you can also get stuck building too many things at once <lfam>vagrantc: That's not trivial to do in the installer <lfam>But, it does / did work :) <vagrantc>i honestly haven't used the installer since it had a frontend :) <vagrantc>and i only used the older installer a small number of times... <lfam>The fix was in the guix-daemon itself, so updating to get the fix will be like `guix pull && sudo -E guix system reconfigure /etc/config.scm && sudo herd restart guix-daemon` <lfam>Or, instead of restarting the guix-daemon, rebooting <lfam>That first update will be a whopper. It's been several months since 1.2.0 <lfam>We are in the final stages of preparing 1.3.0 now <lfam>Alright, I have to go afk. Welcome! <PotentialUser-34>Thanks again. Once my system is up, is there a simple way to create an image preloaded with some software so that I can quickly deploy to multiple computers(all x86_64)? <vagrantc>i haven't used it, but there's "guix deploy" to install on remote machines <vagrantc>but ... i think it needs some guix already installed for it to work <PotentialUser-34>So I guess I'll have to make a copy of a minimal updated install, then try "guix deploy"? <PotentialUser-34>Oh I completely missed the "Building the Installation Image" section in the manual, oops <vagrantc>well, that's to build the image to run the install, not building images you actually install <PotentialUser-34>I don't really understand what the difference is. I can't pass it a configuration file specifying which software it should create the image with? <apteryx>roptat: I'm smoke testing the rc1 locally <apteryx>if it tests good I'll regenerate it locally (I have to figure a way to gain access to the armhf and powerpc64le offload machines from my local machine for GPG signing -- probably wireguard) <apteryx>I'm hoping I can do this either tonight or more likely tomorrow <vagrantc>haha... building the debian package of guix on ppc64el :) <apteryx>One thing which I want to check/understand is why the Guix package inside the 'make release' generated guix-binary-1.3.0rc1.x86_64-linux.tar.xz archive is /gnu/store/rsya5hkyq3fixl2r36lq2g892jadq1fc-guix-1.2.0-21.4dff6ec <apteryx>no, it's update to 1.3.0rc1 (the tag) *vagrantc always found that a tricky chicken-and-egg thing <apteryx>so the way the binary guix tarball is built is 1. build source release (dist target) 2. update guix package to latest commit (with tag name, e.g. 1.3.0rc1). 3. build the latest guix package (the one just updated) and 4. generate a traball with ./pre-inst-env guix pack guix [...] <apteryx>for some reason, unless I goofed something, './pre-inst-env guix pack guix' at this point doesn't pack 1.3.0rc1 but the previous Guix it knowns about <apteryx>I'll retry it manually to ensure that's the case <apteryx>I see for the system installer we update the package twice and generate the install image after the 2nd bump <apteryx>perhaps we should bulid the binary tarballs after the 2nd bump as well <apteryx>sneek: later tell civodul lfam sorry about the hostname change on berlin, I meant to type 'host' to check its IP but apparently typed hostname :-) <raghavgururajan>While building guix from git, is it possible to run `make` by using all cores? <nckx>The âjobâ/âcoresâ distinction as in --max-jobs/--cores is specific to Nix/Guix building. Just always use âmake -j $(nproc)â and be happy. <nckx>If you have a ridiculous number of cores building Guix won't use all of them no matter what you set; IME it can manage about 8 and even then only sporadically. *vagrantc confirms the ~8 used cores <nckx>apteryx: Oh, mystery solved! <Noclip>Why is writing package definitions for guix so much more complicated than just following the programms compilation guide? <Noclip>And I'm not talking about issues where the programm devs forgot to list a dependency in their guide. <raghavgururajan>Noclip: Every package management tool posses a custom build script, based on its design. For example, Arch's PacMan uses PKGBUILD. Likewise, Guix uses scheme expressions (package definitions) as build script. <raghavgururajan>Noclip: You mean programms compilation guide as in make, pip etc? If so, Guix uses variety of build-systems, which can be chosen based on the program/project. Examples: gnu-build-system, cmake-build-system, meson-build-system, python-build-system etc. <Noclip>raghavgururajan: I'm also not talking about writing scheme code here. <Noclip>What I mean is that most package definitions are somewhat long and do things like passing over compiler flags, patching the source or customizing the build process while on other distros a simple "make install" seems to be enough. <raghavgururajan>It's not that hard/complicated as you think. (I felt that way in the beginning too. But after getting my feet wet, shit got interesting.) <raghavgururajan>> while on other distros a simple "make install" seems to be enough. <raghavgururajan>Is it? If I look at Arch (which follows KISS), you can add patches, pass flags and customize build process; in PKGBUILD file. <raghavgururajan>Noclip: Btw, fields in Guix's package definitions are optionally chosen. You don't need patches field if there no patches. No need to pass flag if there is no need. <Noclip>In the last two days I tried writing my first package definition and it took a lot of time, learning and help from other people to make the compilation process not fail at some point. <raghavgururajan>For most simple package-definition, you can take a loot at GNU Hello example mentioned in the tutorial I shared above. <Noclip>raghavgururajan: So many package definitions in the package repo are much longer than they would have to be to just work? <raghavgururajan>> Noclipâ: In the last two days I tried writing my first package definition and it took a lot of time, learning and help from other people to make the compilation process not fail at some point. <raghavgururajan>I had this experience on my first pack-def too. It will become easier as you learn more about how guix works. <Noclip>But why do I need to pass over build flags an other custom stuff at all if on distros like Ubuntu that's not needed? <Noclip><raghavgururajan "(did you get my full message?)"> Yes, I think so. <raghavgururajan>PART 1: Well, pack-defs of some packages will be longer or has custom stuff than its equivalent in other distros. Most of the time, this due to alter build-process/installation to fit the <Noclip>I tried to package bees for btrfs (https://github.com/Zygo/bees). The programms documentation recommends "$ apt -y install build-essential btrfs-progs markdown && make" to compile it on Ubuntu. <raghavgururajan>Noclip: Well, just for compilation, you can of course use make. But for packaging bees into ubuntu, there is lot more. <Noclip>The equivalent guile expression of that line failed the compilation at several points until I added several build-flags and modified the compilation process. <raghavgururajan>You can even use program upstream compilation guidelines in Guix. But for packaging that program into Guix, you have to write package-definition. <vagrantc>Noclip: a big thing that makes guix packaging more complicated is that there are not default library paths ... so you have to be explicit with them. most distros just use whatever version happens to be in /lib or /usr/lib and so on with numerous other assumptions <jackhill>Noclip: I agree with raghavgururajan that it does get easier with time, but it really depends on the software and how much care needs to be taken to build it. Bees is a little more work than other things (e.g. eovim https://issues.guix.gnu.org/47963) <Noclip><raghavgururajan "You can even use program upstrea"> But that would bascially make the programm invisible to guix and so prevent you from using any guix feature on it, right? <jackhill>and polishing things up to Guix standards does take time and experience. note that even for the easy to get workign eovim package, I still went through four revisions :) <jackhill>but the end result is more satisfying ;) ***amfl_ is now known as amfl
<raghavgururajan>Noclip: For example. for you bees, you can go the program folder and do`guix environment --pure --ad-hoc make btrfs-progs markdown`. You will go into a pure environment. You can make there. <Noclip>jackhill: You are the one that already messed with bees and helped me out, right? <jackhill>Noclip: yep, indeed. I had encountered other software before that needed similar tricks <jackhill>oops, looks like it's bedtime for me. Take care all! <raghavgururajan>Noclip: You can of-course do `guix install make btrfs-progs markdown && make` (like `apt -y install build-essential btrfs-progs markdown && make`). But this will polute your profile (that is packages gets installed in your default profile. Also, make here will in an impure environment (like on any other distros). <Noclip>jackhill: As I already told you I got the build process to work but the installed application isn't working at all now :( <jackhill>Noclip: yep, I saw that. Hopefully you'll get it working. I should get back to working on it too, but I have so many projects going :) <raghavgururajan>Remember that you cannot do `make install`. Because of reasons vagrantc mentioned. <jackhill>bees also has that shell script that I was trying to get working, and shell scripts have particularly bad impedence matching with Guix's different locations for things. <raghavgururajan>Noclip: Contributing or working in Guix may *seem* complicated at the beginning. But as you go, you'll end up with bliss and appreciate its elegancy. :-) <raghavgururajan>Take some time to read the above links I shared, especially the packaging tutorial blog post. They will be very useful for you. :) <raghavgururajan>Every time I re-read the manual, I end-up understanding something new. Its called Guix Effect. You'll get use to it. :P <raghavgururajan>Noclip: Hope I was able to help you with some information. Bye now o/ *raghavgururajan + zopiclone = zzZ <raghavgururajan>> Noclipâ: jackhill: As I already told you I got the build process to work but the installed application isn't working at all now :( <raghavgururajan>Feel free to post the run-time errors via paste-bin here and/or via email to help-guix@gnu.org. *raghavgururajan now really goes to sleep ***apteryx is now known as Guest32259
***apteryx_ is now known as apteryx
<efraim>does anyone else using wayland find that sometimes maximizing icecat messes with the graphics? I found if I repeatedly maximize and un-maximize the window it fixes itself <Noclip>This is my current package definition for bees: <Noclip>It compiles fine but after installing it the actual "bees" binary seems to be missing. The "beesd" binary is available but running "beesd" just complains about bees not being available: <Noclip>realpath: /libexec/bees: file not found <rekado_>does it look for files in /libexec/bees or in /gnu/store/âŚ-bees/libexec/bees? <rekado_>if itâs the former you may need to patch it to respect the configured prefix <Noclip>Mhh actually bees seems to be available inside libexec but guix doesn't put libexec into PATH. <rekado_>but Guix did not install things into the root file system <Noclip>(I "installed" it using "guix environment --ad-hoc -l bees.scm") <Noclip><rekado_ "but Guix did not install things "> No <Noclip><rekado_ "does it look for files in /libex"> beesd seems to be looking in the root fs (/libexec/bees) as adding bees to PATH didn't help. <efraim>just a few quick changes, I didn't actually test using it <Noclip>efraim: That seems to be working, thanks! <balance>Hello, please help with next issue. Installed guixSD on i686 with xfce (guix pull and reconfigure ok), but see "Oh no! Something has gone wrong. A problem has occurred and the system can't recover. Please contact a system administrator". In /var/log/messages see this : "gnome-session-binary[363]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus. Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedes <valerii_leontiev>Hey guys. Is it possible to add different entry managers (gdm, lightdm) into installer? Or even drop any of them. And it would be nice to see sway and hikari in window managers option... <Noclip>valerii_leontiev: I guess you just need to change your OS definition for that?! <Noclip>Is there something like 'guix build --file' and 'guix environment --load' for 'guix pack'? <Noclip>Can I somehow do that with 'guix pack --expression'? <valerii_leontiev><Noclip "valerii_leontiev: guix isn't a n"> Lol. It already has installator. Why not? It's just few options <Noclip>valerii_leontiev: You do not just need to install an OS but also maintain it. <Noclip>Which means at least upgrading it from time to time and there you won't get around the command line. <Noclip>And if you want to change any configurations at some point you also have to mess with Scheme code. <Noclip>efraim: If I use "guix environment --pure" it still doesn't find the "bees" binary. <Noclip><Noclip "Can I somehow do that with 'guix"> Looks like -e '(load "filename")' is doing exactly that. <Noclip><Noclip "efraim: If I use "guix environme"> This is really confusing me! How is it even possible that it's finding bees in a non-pure but not in a pure environment? <Noclip>bees is installed through guix so it should be available in both environments?! <leoprikler>bees should only exist in the pure one if you added it to the environment <Noclip><leoprikler "bees should only exist in the pu"> But I did?! <Noclip>It's defined by my package definition which I added to the pure environment. <Noclip>That definition adds two binaries: "bees" and "beesd". <Noclip><leoprikler "Ahh, I found it in the logs"> That's not up to date. <Noclip>bees isn't even installed in my system outside of any environment. <leoprikler>looking at the output of guix build, it seems only beesd is in sbin <leoprikler>in any case, pure environments do what I'd expect, you get beesd, but no bees <Noclip>leoprikler: According to the bees developer it's normal that bees is not in PATH. <Noclip><leoprikler "in any case, pure environments d"> But why do I get bees in the non-pure environment? <leoprikler>probably because somewhere in your PATH you do have bees <leoprikler>non-pure environments don't clean up those variables for you <Noclip>leoprikler: But whereis bees can not find it in the non-pure environment, too. <Noclip>"which bees" also doesn't find it in both environments. <Noclip>Somehow beesd finds it in the non-pure but not in the pure environment. <leoprikler>look into beesd, it probably does something weird <nckx>raghavgururajan: <Woah!> Half an hour or so? Things to do. People to eat. <nckx>Hi Noclip. How can I run beesd on a loop mounted image? It seems to insist on an UUID string instead of using a mount point or device. <Noclip>nckx: Mhh, I don't know but I can ask the bees dev. So far I didn't really try running bees but just checked if it is capable to print out a help message. <nckx>Same here, Noclip. Please share error messages when they might be relevant. The error message you get in a pure environment is quite clear. beesd uses coreutils to find bees, so coreutils needs to be in the pure environment. <nckx>We can remove that requirement by patching "realpath" in the source, or something like that. Haven't looked at the latter. <nckx>(Why does it use realpath at all?) <Noclip>When I create the environment I get the following error messages: <Noclip><nckx "Hi Noclip. How can I run beesd "> The bees dev said "beesd relies on udev to set up /dev/disk/by-uuid/$UUID". <Noclip><nckx "Same here, Noclip. Please share"> According to the bees dev it's somewhat normal if "beesd -h" prints out some errors before and after the help text. <nckx>That doesn't cover all cases. I have a mounted btrfs for testing this package but it can never have that link. That's unfortunate. <Noclip>nckx: Maybe you should join #btrfs. The bees dev's name is Zygo and he is right now active in the chat. <Noclip>Yea, with --pure it's not printing any help text at all because it needs bees for that but can't find it. <nckx>And instead it tells you why it can'tfind bees (it can't find realpath, which is in coreutils). <nckx>I was already in #btrfs so I can just read their answer. <nckx><all paths are burned into the installed beesd script> Isn't quite true or this wouldn't have happened. $PATH *is* looked up at run time, not burned in. <Noclip><nckx "And instead it tells you why it "> Ohhh, now I understand the issue! <Noclip>Looks like coreutils isn't the only missing dependency here: <nckx>I didn't look at the link yet but you'll need at least util-linux or util-linux-with-udev for âuuidgenâ. <nckx>...and awk, and grep đ <nckx>Noclip: This is the only reason Guix packages are often longer. Packages rely on assumptions that aren't true (can't be true, or it would no longer have its features, or would waste time on complex virtualisation of them) on Guix. <nckx>s/only/most common/, e.g. non-free/bundled code. <Noclip><nckx "*uuidparse"> Not sure if that's still used. Zygo said it would be deprecated and removed it from the compilation code two days ago because it caused issues through compilation for me. <nckx>Well, it's still in the version we're packaging. <Noclip>(It was already deprecated long before I tried to compile it, the compilation code was just still referencing it.) <Noclip><nckx "Well, it's still in the version "> That's weird. <nckx>I didn't check to see whether it's required; try removing â"coreutils"â from the wrap phase and see if it still runs! <nckx>It might use other coreutils though. Many shell scripts do. <Noclip>We are packaging the newest commit. <nckx>scripts/beesd.in: if uuidparse -n -o VARIANT $1 | grep -i -q invalid; then ÂŻ\_(ă)_/ÂŻ <apteryx>interesting... are unauthenticated commits silently ignored by Guix? I have a bump of the Guix package itself to version 1.3.0rc1 in my tree; but running './pre-inst-env guix build guix' returns /gnu/store/rsya5hkyq3fixl2r36lq2g892jadq1fc-guix-1.2.0-21.4dff6ec <apteryx>I'd have expected an error or warning at least <Noclip>nckx: "util-linux+udev" Why is that working and what is that doing? Isn't the package called "util-linux-with-udev"?! <Noclip>(I didn't check if it is working) <Noclip>apteryx: Isn't ./pre-inst-env meant to be used on work-in-progress repo versions? <apteryx>it's used to use the Guix from the source <apteryx>the 'release' target makes use of this <apteryx>so if you bump the guix version locally and and do ./pre-inst-env guix build guix, it should build this new version <apteryx>hmm, no, that's not it (I've now signed the bump commits and the result is the same) *Noclip doesn't know the answer. <Noclip>nckx: What's that new wrap-phase/script for? <Noclip>Isn't it also working by just adding the missing depdencies? <nckx>That's what the phase does, add references to the required tools. <nckx>Don't confuse inputs into the build environment with the âdependenciesâ that other package managers use. <nckx>Noclip: util-linux+udev is the name of the scheme variable with value (package (name "util-linux-with-udev") ...). Probably because â+â is disallowed in store file names, although I didn't verify that. <Noclip><nckx "Don't confuse inputs into the bu"> But those packages aren't needed at compile time?! <Noclip>It compiled sucessfull without them all the time. <Noclip>What's the difference between the first and the second part in the inputs?: ("guile" ,guile-3.0) ***hitchcock.freenode.net sets mode: +o ChanServ
<apteryx>stale go file it was. I wonder how's that possible; that'd be a bug in Guile, no? ***ChanServ sets mode: +o nckx
<apteryx>e.g., 'rm gnu/packages/package-management.go' fixed the problem <nckx>Noclip: btrfs-progs isn't needed at compile time either. <nckx>It's true that the inputs I added aren't used by the Makefile to build the binaries. I just pass them into the build environment to conveniently pick them out of âinputsâ. That's an alist, by the way (âassociative listâ), a dictionary. The "guile" (a string) in your example is the key, guile-3.0 (a variable name) the value. (assoc-ref list key) is how you look up an alist entry. <Noclip><nckx "Noclip: btrfs-progs isn't needed"> I didn't specify it for compile time. It's needed at runtime so I specified it as input and not just as native-input. <nckx>You can actually remove âbtrfs-progsâ completely, it has no effect. <Noclip>nckx: The install documentation says "Needed at runtime by the service wrapper script." <Noclip>But every btrfs user has btrfs-progs probably already installed so it won't matter in the end. <nckx>Then it needs to be added to the list in 'wrap. As written, you're just adding it to the build environment but it's never used. Inputs aren't ârun-time dependenciesâ as in some other package managers (notice the pattern? :). They are inputs into the build environment and live no longer than that. <Noclip>Do you think I should remove it from the definition? <nckx>No, add it to the list if beesd invokes âbtrfsâ. <apteryx>any idea how to clear one cache failure registered by the guix-daemon when using the --cache-failures option? <nckx>guix gc --clear-failures DRV... <nckx>To clear all: guix gc --clear-failures $(guix gc --list-failures) <apteryx>ah, 'specified store items'. Great. I thought it was global in effect (no args) <Noclip>nckx: The cookbook says about inputs: "Installed in the store but not in the profile, as well as being present at build time." <Noclip>And about native-inputs: "Required for building but not runtime â installing a package through a substitute wonât install these inputs." <nckx>â[I]nstalling a package through a substitute wonât install these inputsâ applies to inputs as well. So inputs are present in the store and available during the build. But if the user doesn't have btrfs-progs installed into their profile, bees won't âseeâ them, and they can be garbage collected (= deleted) at any time. <nckx>The solution to this is to keep a *reference* to btrfs-progs in bees, which simply means that the string /gnu/store/...-btrfs-progs-... occurs anywhere in /gnu/store/...-bees-... <Noclip>What's the difference between inputs and native-inputs then? <nckx>When not cross-compiling (= normal build), none at all. <nckx>When cross-compiling, inputs are of the target architecture type, and native-inputs of the host type. <Noclip>Why is the cookbook not saying that? <nckx>I've never read the cookbook. <nckx>Inputs is not Guix-speak for âdependenciesâ. âNativeâ is not Guix-speak for build-time, âinputsâ aren't ârun-time dependenciesâ. They are completely different things. Don't map terms from other package managers as synonyms onto Guix or you'll continue to be confused. <civodul>apteryx: re hostname, good, now we know :-) <civodul>apteryx: BTW, be sure to join guix-sysadmin if you're not subscribed yet ***hitchcock.freenode.net sets mode: +o ChanServ
<Noclip>nckx: Wow the guix manual does an even worse job at explaining inputs: "The inputs field specifies inputs to the build processâi.e., build-time or run-time dependencies of the package." or at another point: "These fields list dependencies of the package." <civodul>apteryx: i've just touched version-1.3.0: i removed the WIP commit, and cherry-picked bug fixes <civodul>i suggest that we stop rebasing it now <civodul>so we can no longer have a WIP commit on top, but that one was mostly auto-generated anyway <civodul>i'm kicking berlin so "make assert-binaries-available" passes <civodul>chikamungus: hi! is this on a new Guix System installation? <chckyn>Aside form user created files, which Guix files are required to restore a system onto another host? Is it /etc/config.scm and each $HOME/.guix-profile and nothing else? <roptat>chckyn, you'll need the guix version too (guix describe) <roptat>that is, if you want to reproduce the profiles bit-for-bit <chckyn>Is there a canonical way to perform the operation I'm talking about? At the moment, I'm trying out Guix System in qemu and plan on migrating the setup to a VPS. <roptat>the issue with $HOME/.guix-profile is that it is usually created with procedural comands (like guix install, guix upgrade, guix remove, etc), and that doesn't play well with reproducing the profile <roptat>if you have a manifest, it's a lot easier, since you only have to preserve the manifest and /etc/config.scm <chckyn>Can I not use the manifest in $HOME/.guix-profile/manifest? <roptat>no, it's a different format, even though it has the same name <roptat>it's not usable with guix package -m <roptat>oh, but we have a --export-manifest option now <chckyn>Ah. How should I maintain a manifest over time that would be compatible with guix package -m? Should I version control that manifest off to the side? <roptat>you can start with "guix package --export-manifest" <chckyn>> oh, but we have a --export-manifest option now <chckyn>cool! i think that answers my question then <chckyn>so it sounds i need two files (for a single user system): /etc/config.scm and guix package --export-manifest <roptat>yes, and if you use more than the default guix channel, also your ~/.config/guix/channels.scm <chckyn>Oh, and I need the version of guix <chckyn>how would i integrate that version into the rebuild on the new system? <roptat>when you run guix pull, you can specify the version with --commit <chckyn>I think the only lingering thing I have in mind is the passwords on the system. I suppose those would be setup upon initial installation of Guix System, and then the files we just discussed would apply on top of that. <roptat>you can specify an initial password for users in your config.scm, but the installer can also set them <roptat>once the system is initially installed, you can guix pull, reconfigure and install the manifest <roptat>if you want to, you can also use the manual installaton process to run guix pull from the installer, and initialize the system with your own configuration file, but in both cases, you'll have to log in on the new system to install the manifest <roptat>(and run guix pull too, otherwise your guix will be a bit older and you might downgrade the system later) <chckyn>I see. I think the manual installation is what I'll likely aim for. I'll probably avoid keeping passwords in the config.scm and can set them up during the manual install. Though for a system with lots of users (not just me), I'm sure migrating passwords would have to be done in some way. <chckyn>Another issue I need to come through is how to make the config.scm available on the new system in the first place. I'm sure I can figure that out though. <roptat>when you reconfigure with a recent enough version of guix (post 1.2.0 I think), you should have a /run/current-system/configuration.scm file that corresponds to the file used to init/reconfigure the system (as long as there is only one file and no additional custom modules) <roptat>it's a copy of the file you pass as argument to guix system init or guix sysetm reconfigure <chckyn>I was thinking more along the lines of being in installer and wanting a local copy of the config.scm. Now that I think of it though, I suppose I could simply copy and paste and be done with it. Is ssh/scp one of the tools available while in the manual installer? In that case I could grab it from another system. <chckyn>Another option would be to provide an additional block device with the config.scm preloaded onto it. <chckyn>(Also realizing now that the file-systems configuration may depend on each host, so the config.scm can't necessarily be copied verbatim between hosts.) <apteryx>civodul: re version-1.3.0, sounds good <chckyn>Thank you for the assistance roptat! signing off for a bit <balance>Hello, please help with next issue. Installed guixSD on i686 with xfce (guix pull and reconfigure ok), but see "Oh no! Something has gone wrong. A problem has occurred and the system can't recover. Please contact a system administrator". In /var/log/messages see this : "gnome-session-binary[363]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus. Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedes <civodul>balance: hi! where and at what point do you see that message? *vagrantc eagrely awaits 1.3.0rc* tags <vagrantc>of course, now i have to play the disable-all-those-pesky-tests-that-use-bootstrap-binaries game <civodul>i guess we've never been this close to an RC :-) <vagrantc>i've basically been marking all those tests as "needs network" <vagrantc>but obviously, that isn't upstreamable, since guix itself has a way of running them without network <vagrantc>but it's a *lot* of tests ... not sure how to do that correctly <vagrantc>actually, i think i've also just been outright disabling some of them to ... :/ <vagrantc>at least i can take advantage of speedy ppc64el machines available for building :) <balance>civodul: on the screen. Think that something with xinit gdm xfce ... <balance>civodul: console works excellent. which xinit "which: no xinit in (/run/setuid-programs:..." <apteryx>civodul: I think so too! I'm building armhf-linux stuff on berlin at the moment (this time, really for 1.3.0rc1 -- a stale .go file had me building 1.2.* from the 14th of April earlier... <apteryx>I still don't understand how that could happen (the version string, among other things, of the guix package in the package-management.go apparently didn't match what was in the package-management.scm source file contained), even after re-running make multiple times. <apteryx>that probably explains why I didn't get 100% substitutes coverage from my home machine (on the home machine, it probably *was* trying to build 1.3.0rc1, but on berlin it had only built 1.2.*) <civodul>apteryx: i think you really have to run "make release" on the machine where you sign commits <civodul>otherwise we won't be able to have those changes in version control <civodul>re NEWS, we'll take care of it after the RC <apteryx>civodul: yes, my plan is to run 'make release' on my personal machine where I signed commits after having it build on berlin; I'm not expecting to have much to build at this point (if at all?) <apteryx>I also think NEWS can wait after the first RC is out <Noclip>What's the official/recommended way to specify runtime dependencies in package definitions? <vagrantc>Noclip: inputs or propegated-inputs ... i think <vagrantc>hrm. getting some intermitant issues building guix on debian: GC Warning: Failed to expand heap by 7192576 bytes <vagrantc>GC Warning: Out of Memory! Heap size: 3144 MiB. Returning NULL! <vagrantc>this is from an old version-1.3.0 commit ... anything like that fixed in the new and improved rebased version-1.3.0 ? <Noclip>vagrantc: nckx told me inputs are only build time dependencies. <Noclip>And propegated-inputs suck because they add all the stuff to your profile ... <vagrantc>pretty sure inputs are both run-time and build-time <Noclip>vagrantc: I thought that, too. The manual/cookbook makes one misunderstand it. nckx told me native-inputs are only different from inputs if you use cross-compiling. <vagrantc>e.g. things that are only run for test-suites typically end up in native-inputs <Noclip>I tried adding some needed runtime dependencies as inputs and they were not available at runtime so it looks like nckx was right about that. <vagrantc>if it's linked at build-time, it should be available at run-time <vagrantc>but you have to make sure it gets linked properly... <Noclip><vagrantc "if it's linked at build-time, it"> That's the issue, it is (by default) not linked at build-time but needed at run-time. <Noclip><vagrantc "but you have to make sure it get"> Then I correct my question: What's the offical/recommended way to make sure it gets linked properly? <Noclip>Is there some sort of universal template for that? <vagrantc>Noclip: if it's not linked at build time but needed at run-time, it needs to be in propegated-inputs <vagrantc>or something the user needs to add manually (e.g. some plugins) <vagrantc>regarding the HEAP size issue ... the machine it was running on had 140GB of memory ... so i find it hard to imagine running out of ram is the issue <Noclip>vagrantc: nckx added a new build phase to my package definition which made sure the dependencies are linked at build-time but that looked a bit complicated and hacky to me. <Noclip>That's why I asked if there is some sort of official template to do that. <Noclip>This looks like a very important task to me so I expected it to be documented and explained somewhere in the maual or cookbook but so far I didn't find it there. <samplet>Noclip: Guix determines run-time dependencies by searching the result of the build looking for references to the store (â/gnu/store/...â). <samplet>If your package needs something and it is not looking in the store for it, thatâs a problem. <samplet>I bet nckx added a phase that translates, say, âgawkâ to â/gnu/store/.../bin/gawkâ or some such. <Noclip>That's the phase which nckx added. <samplet>Aha! It creates a wrapper so that the program gets run with the âPATHâ variable populated with some fundamental tools. <samplet>In the end, that means that âcoreutilsâ, âgawkâ, âgrepâ, and âutil-linuxâ are specifically mentioned in the build output (because they end up in the wrapper script). <samplet>The wrapper script will have âPATH=/gnu/store/...-coreutils.../bin:...â, and Guix will notice that store path and consider coreutils are run-time dependency. <Noclip>samplet: That sounds somewhat hacky, doesn't it? <samplet>Kinda, but it works *extremely* well (and has for many years)! <samplet>It is what Nix does, too, so there are tens of thousands of packages working nicely this way. <Noclip>What's that wrapper script doing then? Is it used at all on run-time? <lfam>Maybe it looks hacky to you, but it's exactly the "Guix way" to do it <lfam>There's no better way to handle these things for shell scripts <lfam>And for other languages, it's an upstream bug if the program can't keep track of its dependencies <samplet>Yeah. The regular program gets renamed to â.XYZ-realâ and the wrapper script gets the proper name âXYZâ. When you invoke âXYZâ it sets up the PATH variable in a way that makes the real XYZ work, and then calls the real XYZ. <Noclip>Wouldn't it be better to add a new field for that like "runtime-inputs"? <Noclip>(Could also use any other name ...) <peanutbutterandc>Hey there, does anyone here understand rsync --include --exclude pattern cascade? <peanutbutterandc>Here's what I want to do: backup my home directory. Except for the dot files. But I need to backup this .subdir and all the .files inside that subdir <Noclip>Actually I was somewhat waiting for someone to ask that on irc xDD <peanutbutterandc>I used `rsync --include=".subdir" --exclude=".*" source destination` and it did rsync the .subdir. But didn't rsync the dot files therein <samplet>Noclip: The short answer is ânoâ. :) The âwrap-programâ procedure is already pretty helpful. It might make sense to do something special for shell scripts and the PATH variable, but it would depend on how often it comes up. <lfam>"propagated-inputs" *are* runtime inputs <lfam>The probably is that the program needs to actually know where to look, which is where this bees program falls short <Noclip>peanutbutterandc: If you can specify the full path to the directory or file that you want to include then I wouldn't use include rules for that. <lfam>I mean, the "problem is that the program needs to know" <Noclip><peanutbutterandc "Here's what I want to do: backup"> Mhh this sounds actually more complicated than I expected. <Noclip>peanutbutterandc: I think the easiest thing you can do here is using two seperate rsync commands. <Noclip>The first syncs everything except the dotfiles and the second one syncs only .subdir and it's contents. <Noclip>Yea, if you can I recommend you to avoid include rules. They can make everything much much more complicated. <lfam>efraim: Do you ever use the Enlightenment media player 'rage'? I tried it and it just shows a blank checkerboad <peanutbutterandc>Hmmm... okay.... just... a few more webpages... and then i'll stop. Thank you for the suggestion. (: <lfam>It's definitely possible to do what you want to do <Noclip>peanutbutterandc: What I prefer currently is using "-R"/"--relative" and several source directories/files. <Noclip>But that might not be a good choice in your situation. <ss2>Can I force rebuilding a package inside an environment? <Noclip>peanutbutterandc: Do you want to exclude all dotfiles recursively or just those in the top level source directory? <samplet>PotentialUser-55: In Scheme, you can use âfold-packagesâ (although it doesnât seem to be in the manual). <ss2>*guix environment. I'm testing building a package. Now it always responds with a link to a store item. <peanutbutterandc>Noclip, lfam Just managed to do what I wanted to do usiing --include=".subdir/***/.*" --include=".subdir" --exclude=".*" <peanutbutterandc>...but I would be glad to learn of better ways... let me read what you've sent me <lfam>ss2: Yes, you can use the --check argument <lfam>Any command that build things should take that argument, ss2 <Noclip><peanutbutterandc "I used `rsync --include=".subdir"> Because you told it to exclude dotfiles recursively. The include pattern only keeps .subdir but not it's contents as it doesn't match on the contens. <Noclip><peanutbutterandc "Noclip, lfam Just managed to do "> That's actually smart I think. <ss2>okay. It says that it sucessfully build `store-item', but it didn't to this usual build process. <lfam>ss2: You probably should also pass --no-grafts <lfam>Otherwise you only "check" the build of the grafting <peanutbutterandc>Noclip, Thank you. Always feels good to be complimented by a GNU hacker. (: Is there a way to tell it to exclude dotfiles only on the top dir? I read somewhere that if I started the pattern like "/.*" so it'd only exclude at the top level but it didn't and polluted my backup <Noclip>Can you try --include=".subdir/***" --exclude=".*"? I think that should do exactly the same thing. <lfam>In general, unless you are testing something related to grafts, you should always pass --no-grafts when testing the build of things, ss2 <lfam>When you want to actually *use* the package, then you should allow the grafts to occur, because they provide security updates <Noclip><peanutbutterandc "Noclip, Thank you. Always feels "> Mhh that should work. <ss2>alright! Thanks, that's doing the trick. <peanutbutterandc>Noclip, No, it copied .cache and stuff from my home to the backup. I don't know what Im supposed to make of it <Noclip><peanutbutterandc "Noclip, just want to exclude top"> Then (--include=".subdir" --exclude="/.*") should work I think. <Noclip><peanutbutterandc "Noclip, No, it copied .cache and"> Which command? <peanutbutterandc>Noclip, BTW, --include=".subdir/***" --exclude=".*" also worked just as well. Thank you <peanutbutterandc>Noclip, --include=".subdir" --exclude="/.*" copied .cache and friends into the backup <samplet>Note that it is designed to help archives find the sources to our packages. <Noclip><Noclip "Can you try --include=".subdir/*"> Ohhh Element (the client I'm using for this chat) deleted two "*" here. But it looks like you already corrected that on your own :) <Noclip><peanutbutterandc "Noclip, BTW, --include=".subdir/"> Keep in mind that this is also excluding dotfiles recursively! <Noclip><peanutbutterandc "Noclip, --include=".subdir" --ex"> Is .cache directly in the top level source directory? <Noclip>Can you give me the exact path which you specified as source? <Noclip>For rsync /home and /home/ are not the same! <Noclip>correction: /home/user and /home/user/ <peanutbutterandc>Things like these sometimes makes me want to leave computers and never touch it again :| <Noclip>If you only use $HOME (equal to /home/user) your top level directory will be /home/ ! <Noclip>With $HOME/ (equal to /home/user/) it will be /home/user/ ! <peanutbutterandc>Does that mean that I could tell it to --exclude="/*/.*" and it will work? <lfam>The rsync trailing slash thing is notorious <Noclip>So --exclude "/.*" would only exclude dofiles directly below /home/. If there would be /home/.cache it would be excluded by that. <lfam>The man page even has a paragraph about it <Noclip><peanutbutterandc "Does that mean that I could tell"> You could also use --exclude="/username/.*" here. <Noclip><peanutbutterandc "I learned something new today. T"> When I used rsync for the first time several weeks ago I was also completely confused by include and exclude rules. I'm glad to see that I'm not the only one having issues with it xD <lfam>Soon it will be second nature <Noclip><lfam "Soon it will be second nature"> Using rsync? I think it already is at least for some parts. <Noclip>The more I use it I seem to understand why they implemented include/exclude rules the way they did and how it makes the tool highly flexible. <reeloii>Greetings, I use Xfce as a default desktop environment, and now I wish to be able to try EXWM. Any clues on how can I do it? <Noclip>At first I thought their implementation is completely dump ... <Noclip>You're welcome, peanutbutterandc. <Noclip>peanutbutterandc: Here is how I would probably have done it: <Noclip>`rsync [...] -R --exclude="/user/.*" /home/./user /home/./user/.subdir destination` <peanutbutterandc>Hmm... that certainly is far more readable than my labyrinth of --include --exclude patterns <Noclip>With -R you can choose where you want the top level source directory to be by adding /./ in the source path at that point. <Noclip>peanutbutterandc: Let's say you want to include only ".subdir/sub" but not the rest of ".subdir". With include rules that would look like this: <Noclip>`--include="/user/.subdir" --include="/user/.subdir/sub" --exclude="/user/.*" --exclude="/user/.subdir/*"` <Noclip>With -R it would not get more complicated as before: <Noclip>`rsync [...] -R --exclude="/user/.*" /home/./user /home/./user/.subdir/sub destination` <peanutbutterandc>Noclip, What you've just written is somehting that would most certainly be helpful in simplifying my backup script... except I don't fully understand it, yet <Noclip>peanutbutterandc: Adding one more recursion level between the point that you want to exclude and the point to include would force you to also add another include and exclude rule for that level! <Noclip>If you want to include just .subdir/sub/sub you would need 3 include and 3 exclude rules. For .subdir/sub/sub/sub you need 4 include and 4 exclude rules and so on ... <Noclip>peanutbutterandc: With -R you just need to specify /home/./user/.subdir/sub/sub/sub as source once and that's it. <Noclip>> <@noclip:feneas.org> With -R it would not get more complicated as before: <Noclip>> `rsync [...] -R --exclude="/user/.*" /home/./user /home/./user/.subdir/sub destination` <Noclip>(So just replace here "/home/./user/.subdir/sub" with "/home/./user/.subdir/sub/sub" or "/home/./user/.subdir/sub/sub/sub".) <peanutbutterandc>hmmmm.... so the only 'drawback' of -R is that if I have to backup '/home/asdf', I have to specify that source as '/home/./asdf' (?) <Noclip>If that's not visible on IRC: I was referring to `rsync [...] -R --exclude="/user/.*" /home/./user /home/./user/.subdir/sub destination`. <peanutbutterandc>Hmm... I see. It's going to take me a while to wrap my head around it, but I can see that this route is certainly less trouble <Noclip>peanutbutterandc: With recursive exclude rules (like --exclude=".*") it would however not be that simple. Then -R wouldn't help you. <Noclip>Maybe we can sum it up this way: Combine recursive excludes with includes and non-recursive excludes -R. You can of course use recursive, non-recursive, includes and -R in one single rsync command. <Noclip><peanutbutterandc "I see... so -R is to be used wit"> No. <Noclip>recursive exclude patterns are for example "x/y/z" and non-recursive ones are "/x/y/z" (with a leading "/". <peanutbutterandc>Hmm.... I think I'll have to re-read this conversation again a few times. But I think I kinda' sorta' am starting to make some vague sense of this <Noclip>peanutbutterandc: The recursive pattern would match on /x/y/z, /a/x/y/z, /a/b/x/y/z and so on while the non-recursive pattern would only match on /x/y/z and not the other two examples. <brown121407>Hi! Has anyone managed to get CCLS to work with C++ projects on Guix? I can use CCLS on Arch when programming in C++ just fine, but on Guix it seems to not read the standard library correctly, for example it doesn't recognize std::cout. <Noclip>peanutbutterandc: Maybe you should take a deeper look at the rsync man page and some internet documentation. It should be all explained there. Really understanding rsync and it's include/exclude rules is hard and takes some time! <efraim>Sneek later tell lfam I normally use mpv, but when I do use rage I use it like mpv, rage /path/to/file ***mjlbach is now known as aterius
***aterius is now known as mjblach
***mjblach is now known as mjlbach
<apteryx>was there not already something in the default fontconfig setup to fallback to that font? <apteryx>e.g, in fontconfig's package definition, --with-default-fonts is set to font-dejavu <ss2>oh no... I killed another guix system again. <ss2>seriously, did a garbage collection, and rebooted. Now system is kernel panicking. <apteryx>do you have older older system generations to try from the boot menu? <ss2>I had the same problem several days ago on another machine, and now I can reproduce this actually. <apteryx>Could you open a bug with a reproducer? If we can reproduce it that'd be a release blocker. <ss2>It should go along the lines of installing, creating several system generations, then gc the store clean and reboot. <ss2>Unfortunately I use additional channels with a modified kernel. Not that is has to do with that. But will test it. <ss2>Before I delete the root partition, should there be some things to keep for debugging porpuses? Well, the logs obiously.. <ss2>or is there a way to chroot into it to rebuild a generation? <civodul>apteryx: re fontconfig, you're right; i wonder why it's not enough <civodul>maybe IceCat has a different method to look up the default font? <nckx>vagrantc: <things that are only run for test-suites typically end up in native-inputs> I think we agree. They end up there *because* they matter when cross-compiling and it's the correct place, but when not cross-compiling, moving all native-inputs to inputs would *work*, even though it's subtly wrong. <nckx>For some value of subtle. <apteryx>civodul: then perhaps we could special case icecat (to propagate it), if that's the only culprit <apteryx>and leave a note that this could/should be further investigated <apteryx>ss2: make sure to test a vanilla Guix config without any channel for reproducing <civodul>apteryx: i'm not sure if icecat is the only one having problems here <roptat>I wasn't able to reproduce in a VM with the same OS, so maybe something else interfered <civodul>apteryx: i was thinking we could propagate and add a comment explaining why <ss2>apteryx: running a vm testing.. <civodul>roptat: great that you couldn't reproduce it <civodul>i guess we can close as non-reproducible for now, then <roptat>it was a new machine at work, so maybe a technician was working on it when I installed, and that somehow interfered with the script, but I don't really see how... <nckx>civodul: <objections to propagating font-dejavu from xfce and mate> Sounds good. Those packages are meant to just work; people wanting a minimal system don't use them; and it takes away the pressure to propagate fonts from e.g. IceCat itself. *nckx reads on; ...or maybe that question was superseded. <ss2>apteryx: couldn't reproduce with vanilla Guix. Will do further testing though. <nckx>It's rare but it happens. <chckyn>my `herd status` shows `term-auto` is stopped. and when i start it, it fails. what is the `term-auto` service for? <chckyn>Since I'm running Guix System in qemu, I suppose it makes sense then that the serial console service fails to start. Do I have that right? <nckx>I'm not sure. QEMU VMs have a serial console by default (check the menu bar somewhere), but don't ask me more than that. <nckx>You might need to point the kernel in the right direction. <chckyn>ok, thanks. if it turns out i need it for some reason, i guess i'll have to look deeper. things seem to be fine without it for now. <apteryx>ss2: that's a serious bug with the channels you use, if that turns out to be the case. It should be reported to them. <ss2>yes, will test it with the other channels. <ss2>no idea unfortunately.. <ss2>Couldn't scroll back. <ss2>My weird problem is that all generations were dead after garbage collecting. <ss2>and this happened on another machine. So, will try to find out why this is happening. <ss2>It probably hasn't got to do with that the generations where broken. Maybe it is that my modified kernel breaks at some point. <jackhill>rekado_: cool, I didn't know about Jam usage in Boost. The other Jams I looked at aren't being actively developed. If boost's is (and it is compatible), I should probably look into using that to build Argyll <vagrantc>that JAM license doesn't look free to me ... :/ <vagrantc>to fork a discussion already on the list :) <jackhill>vagrantc: although, perhaps it would be better if you replied to the thread *jackhill goes to compare with gnuplot <rekado_>jackhill: not sure the Jam stuff in Boost will be helpful. The files there are distributed under the Boost license. <vagrantc>jackhill: in short, debian's not free from mistakes :) <rekado_>jackhill: if it turns out that Jam cannot be added after all, the way out could be to extract it from Boost (see tools/build/src/engine/jam.cpp in the boost tarball), because itâs also available under the boost license (in addition to its original license). <jackhill>vagrantc: sure, but I have some confidense that their process at least gave it some consideration, even if the conclusion was mistaken :) <jackhill>rekado_: ok. Assuming that Boost had permission to do that. I think the risk is low of Perforce trying to prevent people from exercising their freedoms here (even if they generally do non-free software) <jlicht>Does anybody have a recursive cpan importer gathering dust somewhere? <ruffni>i'm trying to build guix for a foreign system (following the "Guix on an ARM Board" tutrial in the blog). now my machine seems to name the sd-card differently than the target machine (sdb vs mmcblk0). i figured all is well if i change the config file to match my host-system names (and then change them as soon as guix runs on the target). can this work? <ruffni>also i run into a "link: Operation not permitted" error. what is this about? <vagrantc>be sure to use UUID or label for your rootfs definition <vagrantc>you need to run it as root to write to the device, most likely <ruffni>i set a label (for the partition mounted at "/") but guix is unable to find it..? do i _have_ to refer to the label even when remotely building? <vagrantc>i have a lead on getting pinebook-pro to a better state in guix/master