<dadinn>nckx: I just read starting the cow-store... to create a ZFS root I would need the kernel modules before I could set up the installation root (e.g. /mnt in the manual) <nckx>dadinn: Anyway, if you want zfs so you can ‘mkzfsfs /mnt’ to boot Guix off of it: that won't work. <nckx>Guix only supports the following /gnu/store and hence root file systems: 'ext2 'ext3 'ext4 'bcachefs 'btrfs 'jfs 'luks <nckx>…and one of them is made up locally, oops. That should be 'ext2 'ext3 'ext4 'btrfs 'jfs 'luks. <nckx>dadinn: What's mounted on /mnt? <nckx>dadinn: You did restart the VM, right? <dadinn>just with the arguments: `init-instroot.scm -Z`... it would try to do a `guix pull`, then install the `zfs` package <nckx>Uhm, that's 774 lines o' Guile. It does things not supported upstream yet (separate /boot). You should ask the author for support. *kmicu thinks Daniel is the author 🤔 <nckx>Which ‘Unmounts and destroys installation root directory, that has been set up previously by init-instroot script.’ <kmicu>Are you planning to add ZFS support to Guix System dadinn ? <dadinn>yeah, my it's my own baby. It works for Debian, and Arch, I think Redhat and Fedora will be supported by the end of the week... thought Guix would be a nice addition <dadinn>kmicu: the script sets up the root filesystem... combinations of LUKS, LVM, ZFS are currently supported, it generates fstab/crypttab (for GUIX I can easily add an initial system config) <dadinn>The problems for guix is that LVM is currently not supported, and I suppose neither ZFS. So I don't know what to put in the system-config. But firstly, I would need to compile the kernel modules in the live environment, so that I set up the ZFS root filesystem <nckx>For more /gnu you'll need to mount some scratch space somewhere and run ’herd start cow-store /it’. You may need to mount something under /tmp as well if that's giving you trouble. <dadinn>Guix looks even easier, because it seems you already have a package <mbakke>dadinn: you're likely better off customizing the installer instead of compiling things in the live environment <dadinn>nckx: the Manual says that I should be running `herd start cow-store` after I configured the installation root for the new system :/ <nckx>But you're not following the manual. <mbakke>if you have guix installed elsewhere (not necessarily Guix System), you can tweak gnu/system/install.scm as much as you like and create a new ISO with 'guix system disk-image --file-system-type=iso9660' <nckx>The E-Z workflow in the manual expects you to mount the root relatively quickly, so you can cow-store, which basically overlays a hidden directory on /mnt onto /gnu so you get much more /gnu. ***drakonis1 is now known as drakonis
<nckx>The live environment is really not great for significant development as ambitious as yours. <dadinn>nckx: you mentioned earlier i could use /tmp for the cow-store? <nckx>I don't think so, and if so I was wrong (but I don't think so 😛), they aren't related. <nckx>Well, they are, but in a bad way. <nckx>cow-store is exactly a hack to get you out of the world of tiny tmpfses in RAM and put part of /gnu on to real storage. <nckx>You need to do something like mkfs /dev/foo && mount /dev/foo /blah && sudo herd start cow-store /blah. <nckx>Iff you want to build lots of things in the installer before mounting the future root file system at /mnt — which I don't recommend — that's the only way I can see it work. <dadinn>nckx: I tried `mkdir /tmp/cow-store && herd start cow-store /tmp/cow-store`... exactly the same error as before, it runs out of space while trying to build/derive linux-libre-module-builder-5.4.52 104.7MiB <dadinn>I have 4G memory in this VM... and it's failing on a 100Mb file :/ <brettgilio>Hey all, I've been using and packaging for guix for 3 years now and I just realized I am probably doing something in the least efficient way. Anyways, if I need to force a package to fail on the last step before installing is there a convenient way to do this? <civodul>brettgilio: you can add a phase that fails, or just hit C-c during the build <nckx>dadinn: Using /tmp like that won't work, see above. You need to mount *something real* there. Storage. <nckx>brettgilio: I (invoke 'punt). Is that convenient? <dadinn>nckx: can you please explain why? I'd like to understand <nckx>dadinn: ‘mkdir /tmp/cow-store && herd start cow-store /tmp/cow-store’ is like saying ‘there's no more room in my RAM to store /gnu! Instead, store /gnu in my RAM!’. <nckx>That won't work for obvious reasons. It does work if you replace the last word ‘RAM’ with ‘this actual storage device’. <nckx>In technical terms, I think it's just yet another overlayfs. So you're overlaying a tmpfs (/tmp) onto something (/) that was already a tmpfs. <dadinn>nckx: how about I quadruple the RAM for the VM? <nckx>Sure. If you insist on going down this wrong path, quadrupling the brute force will probably even work. <nckx>If that doesn't work, quadruple it again. ***CcxWrk_ is now known as CcxWrk
<dadinn>quadrupling the RAM, and the wine! <dadinn> Fuck, they don't celebrate namedays in UK... so I am drinking to myself alone :( <dadinn>gave it 16G RAM, but it is now building the zfs module... <nckx>What does bzcat <log> say? <nckx>I hope it's something useful. *nckx needs to sleep, good night. <dadinn>nothing really, the build failed... interestingly the 104Mb package which failed earlier linux-libre-module-builder, is was a different version this time: 5.4.31 <hendursaga>I take it using QEMU to build for other platforms while trying to package something would take up more disk space? Does the packages for the other architectures get garbage-collected? <dadinn>hendursaga: there the issue this time wasn't disk space. It says the build just failed :/ <dadinn>earlier whith 4G RAM it ran out of disk space while building linux-libre-module-builder <hendursaga>dadinn: Pardon, I was talking about in general. I'm trying to package something rn :) <brettgilio>Anybody know any neat way to run guix refresh on a specific package module? <bavier1>brettgilio: something with awk? guix refresh $(guix package -A | awk '$4 ~ /gnu\/packages\/games.scm/{print $1}') <bavier1>can use (guix discovery) too, to fold over packages from a module <brettgilio>bavier1: The awk method would be great if the github refresher wouldnt crash about 30 packages in :). I have a github api key set and everything, but after awhile it just borks itself. <bavier1>hmmm, ok, I've seen that before. I don't know if it's a github response thing, or related to specific packages <bavier1>i.e. you might encounter it regardless of which way you ask 'guix refresh' to check ***catonano_ is now known as catonano
***XMoPX is now known as XMOPX
<brettgilio>How do I unpack another packages source directory into a package? <brettgilio>I have a package that uses boehm gc as a submodule and needs the uncompiled version for it to proceed <brettgilio>or maybe i just need to skip the make target, hmm <bavier1>brettgilio: there are some examples, e.g. isc-dhcp, that uses a secondary source and unpacks in a new phase <bavier1>similar can be accomplished with e.g. ("boehm-gc-src" ,(package-origin boehm-gc)) as an input <bavier1>a grep in gnu/packages/*.scm should bring up some examples <brettgilio>Stay tuned, I should have mercurylang.org packaged soon <brettgilio>I've been working on it for some months off and on <bavier1>huh, I hadn't hear of that lang before <brettgilio>bavier1: I've only played with it. I stopped using it when I moved to guix for a few reasons, but I've always wanted to get it brought to guix <bavier1>logical languages are one of those things I haven't been able to explore much yet. <bavier1>they seem really useful for some things <brettgilio>bavier1: I've done a little bit with prolog (I packaged swi-prolog for guix too). But my tool has and remains ML (OCaml/Standard ML) and Scheme. A little C here and there too <bavier1>"The Reasoned Schemer" is still sitting in my to-read list <brettgilio>I am trying to use the snippet as follows `(string-append "gc-" (version-major+minor (package-version libgc-7)))` <brettgilio>But the builder is returning: Wrong type (expecting string): (string-append "gc-" (version-major+minor (package-version libgc-7))) <brettgilio>however I confirmed from guix repl that is indeed returning: $1 = "gc-7.6" <brettgilio>When I did that it says that function is undefned <brettgilio>oh even weirder, it says Unbound variable: version-major+minor <apteryx>brettgilio: that definition comes from (guix utils). Does your module has #:use-module (guix utils) at the top? <apteryx>OK, I can't say more without seeing the thing <apteryx>OK, so you unquote inside your inner list <apteryx>but you're still inside a bigger list <apteryx>so you need to unquote twice I guess <brettgilio>I think I decided to go with version-prefix instead of version-major+minor <brettgilio> (version-prefix (package-version libatomic-ops) 3)) <brettgilio>Its giving me an error about not being able to split the string, which is what version-prefix does, saying that (package-version is not returning a string <brettgilio>(version-prefix (package-version libgc) 3) in a repl works just fine too <brettgilio>I guess so. I am pretty tired, but id like to figure this out before bed <brettgilio>I think im just getting sloppy from exhaustion. So after I figure this part out I should probably stop <apteryx>question: why do you need those map + match-lambdas? <apteryx>it seems you're iterating on a list of just one tuple of 3 elements, which gets passed as arguments to your match-lambda procedure <apteryx>you could instead establish the missing bindings in the top (let ... <apteryx>then proceed with your match-lambda body as the body of the (let <apteryx>this will reduce your fighting with double unquotes :-) <apteryx>I guess the original idea was to reuse the same procedure on two different set of arguments <brettgilio>I went with your idea to just go with the let form and remove the map <apteryx>that's better for late nights. You can refactor the thing after a good night. <apteryx>you could for example let bind a procedure <apteryx>and call it twice, with different arguments (that could have already been computed and bound in the let) <apteryx>I tihnk you can now even use (define at the beginning of the (let body, in Guile 3. <c4droid>Hi, I'm changing my guix system configuration now, I want to combine the bios and uefi system config, the guix have the function to reading the kernel is booting from bios or uefi? ***PotentialUser-66 is now known as Pengu1n
***terpri__ is now known as terpri
<alextee[m]>there's supposed to be a few buttons below "Scenes" and "Sources" <bdju>the descriptions for emacs-helm-org and emacs-helm-ag are the same and I think the one for emacs-helm-org is wrong <bonz060>Talking about guix-past thought it's pre-recorded. <efraim>you can even feed the link straight to mpv <bonz060>efraim: That's not my channel. I don't know how to do that... <bonz060>Can you run guix on MacOS? Someone just asked that, and I have no idea if that's possible. <bonz060>Hmmm... Thanks! I never knew you could do that. <efraim>guix currently has a hard dependency on glibc, so GNU/Linux and the Hurd (in progress), no to MacOS/Windows, no to musl libc <efraim>It was a shot in the dark, it used to be that I needed streamlink <jonsger>i don't understand that error message: In procedure open-file: No such file or directory: "/gnu/store/kb7hp2l4znyxg4aa8fhwin8m02a60sca-ispell-3.4.00/lib/ispell/english.hash" <jonsger>theres something wrong: /gnu/store/kb7hp2l4znyxg4aa8fhwin8m02a60sca-ispell-3.4.00/bin/ispell <jonsger>so I guess I need to somehow wrap this or so ***dingenskirchen1 is now known as dingenskirchen
<u0_a173>Does guix support compressed kernel modules? <u0_a173>My kernel enabled xz as the kernel module compression method, but it made an error during system configuration, and it could not find the module needed by initrd. <nckx>u0_a173: It supports uncompressed & gzipped modules. <nckx>u0_a173: Actually the gzip support may or may not be upstream already (can't find it in the Web interface), but it's definitely coming. <nckx>I'm using it & it works well. <kmicu>[Jokin’] Ludo is bridged from Matrix‽ *civodul still uses good ol' IRC <kmicu>I saw you reconnecting ~3hours ago together with ~140 Matrix users. It could be a plain correlation or I’m onto a new conspiracy theory called The Matrix Ludo Theory. <nckx>All of Matrix® is just ZNC running on Ludo's laptop. <kmicu>That’s even bigger conspiracy theory. I subscribe. It make sense. <civodul>mcron job specs remain pretty hard to grasp for me <civodul>for basic things it's fine, but for like "every Sunday at 9:30", bah <nckx>Cool. I feel marginally less stupid now. <ss2`>Hey, how does one configure the grub bootloader so that you pass linux-arguments to the kernel? I only understand how to do this for manual menu entries, for say, other distros. ***ss2` is now known as ss2
<alextee[m]>anyone know what package provides this? ./sherlock.lv2-0.24.0/subprojects/nk_pugl/glew-2.1.0/GL/glew.h:1205:14: fatal error: GL/glu.h: No such file or directory <nckx>ss2: (kernel-arguments (list "foo=bar" …)) <nckx>The name's a bit of a Linux-centric left-over, I guess. <linka>hi. how would you go about installing an old package version? <linka>the current version of Krita in the repository doesn't work <linka>and i want to try my luck with previous versions <linka>the loading is stuck at "adding resource types", it doesn't crash, just goes forever <lfam>I see, it happens for me too <lfam>You can try old versions with Guix time-machine <lfam>For example, `guix time-machine --commit=$some_old_commit -- install krita` <lfam>The tricky part is deciding which commit to use <lfam>I would try at least a month ago <lfam>You might have to spend a long time compiling <lfam>It's a very heavyweight thing to build <lfam>I'm trying to build the latest version (4.3.0) now <mroh>lfam: it is doing some weird kind of native compiling on some of its library, if i remember right... <mroh>yes, some days ago... but i coudnt solve it, so its another thing in the git stash ;) <lfam>Do you remember any more details? :) <lfam>There's a fix in that Qt report, apparently <lfam>We could try cherry-picking that patch, maybe only using it for Krita <mroh>no, it compiles (and works), but at some point it checks for the compiling processor, so (on my machine) it uses avx, sse2 and what not... <lfam>Some CPU features are considered required in Guix, others are not <lfam>I don't recall the categories <lfam>Often you can tell the compiler to build generically <lfam>In gnu-build-system you'd pass -march=generic <bavier1>we generally don't let packages compile with anything higher than sse2 <bavier1>unless they are capable of doing runtime checks for processor capabilities <mroh>lfam: i couldnt find out how, it also says something about cmake profiles, but my cmake-fu isnt good enough... <lfam>I wonder if it will be effective to only patch the qtbase package used by Krita <mroh>and it looked to me, its was compile time, not runtime... <lfam>Heh, we already have one patched qtbase. Not a great sign <lfam>I'm testing the build now. It will take a few hours ***dingenskirchen1 is now known as dingenskirchen
<linka>thanks! i really love how active this community is <linka>i'm tempted to switch from parabola on my main computer so i can contribute here <mroh>lfam: that native CPU stuff is happening in configure phase, if i remember right, so you should see it early <lfam>mroh: I decided to try patching qtbase instead of building the newer Krita <linka>guix package definitions actually seem much easier to write than PKGBUILDs <mroh>lfam: but then we have another qtbase only for krita. the newer krita just runs, but isnt reproducable w/ that native stuff. seems like a better option, no? <lfam>Well they are both viable options <lfam>It's worth it to send "work in progress" patches to the bug tracker, especially for things like this. Somebody else might be able to solve the issue right away <alextee[m]>linka: once you start writing packages with scheme you can't really go back to any other packaging system <mbakke>lfam: probably grafting that patch is sufficient, right? <mbakke>oh, maybe we don't even need a graft, I saw your patch now <mbakke>odd that only Krita is affected though *civodul sends a patch adding unattended-upgrade-service-type <efraim>I sent my zram service patch just now too <mbakke>unattended upgrades, yaay! I was considering how to implement that just today. <mbakke>lfam: I don't think we have gradle yet, maybe roptat can estimate the difficulty :-) <roptat>mbakke, lfam: next to impossible <roptat>I mean, we can use it, but making a package and build system is really hard <roptat>gradle is built with gradle, and is partially written in kotlin, which itself is written in kotlin and built with gradle <mbakke>doesn't grade predate kotlin by a large margin? would an older version work? <roptat>some parts of gradle are written in scala, but I'm not entirely sure it's required for a working gradle, as long as you don't use it for scala stuff <roptat>anyway, we don't really need to use gradle to build stuff <roptat>we already have packages that are supposed to use only gradle, but that we build with the ant-build-system <roptat>it's a bit hard to build, because we need to replace the gradle build phases with our own, so sometimes that's a lot of work, but it's doable <roptat>just like we build maven from the ant-build-system, even though maven is supposed to be built with maven <roptat>looking at the sources, it's not even that complicated, you use the ant-build-system, specify #:jar-name, #:source-dir to be "src/main/java", no tests, add a copy-resources phase like many other packages, and create a package for all the dependencies <roptat>I recognize about half of these dependencies, the rest will have to be imported <lfam>Hm... Thanks for the insight. It does seem like a lot of work <mbakke>so for this particular package it's "just" about packaging the dependencies and tricking it into build with ant <lfam>Maybe there is another application that will be easier to package. <lfam>I have to play around for a while to see what is the best one to choose <roptat>the ant-build-system automatically generates the files needed to build with ant <roptat>it just ignores the existing build system entirely <mbakke>so after enabling "official" release optimizations, ungoogled-chromium is noticeably faster, and also a good 200 MiB smaller. It's still more laggy than the previous version though. <mbakke>yes, something is amiss since the upgrade to 84, but I'm having a hard time figuring out what <mbakke>ironically changing to the LLD linker increased link times dramatically, but ostensibly because it enables crazy link-time optimizations *mbakke needs to go entertain a cat *NieDzejkob wonders if a git bisect would help <jonsger>I really don't understand why `guix system reconfigure` builds so many derivations (hundreds) and doesn't get many substitutions. do other also have this problem? <lfam>jonsger: You do get some substitutes, right? <mbakke>NieDzejkob: bisecting would work if I had 1) enough disk space for the checkout, and 2) a computer that needs < 8 hours to build the thing :P <lfam>Are you building from a very recent Git commit? <jonsger>yes, but it was so for the last whole weak on even settled commits. Still the same package, at least it looks so <jonsger>ah I meant packages because they are hundreds <jonsger>usually I only have to build icecat, icedove and some others (often some MATE packages which I don't understand why) <lfam>I've found that certain packages are never built on the CI server (borg, syncthing). I don't use icecat, icedove, or MATE, so I can't compare <lfam>I'm not sure what's wrong <lfam>I don't know about MATE, but for the others, the common factor is that they might take a long time to build and require lots of I/O <jonsger>and are often triggered for rebuilt because they are big leaf packages <jonsger>I removed chromium, because it was the same. So I use now one directly from my local gnu/store :P <lfam>It's weird because I think we definitely have the power to build these things <jonsger>I don't understand cuirass, tbh. I didn't get it set up for the simplest task... *nckx smiles madly while their eyes bleed. <bavier[m]1>do gnome-related packages need to be updated in lock-step? <bavier[m]1>e.g. can a 3.32 package be update to a 3.36 package as long as things build etc? <mbakke>nckx: lol, neat :-) I'm tempted to do the other way around, so that I can generate my Emacs config from Scheme.. <mbakke>I think we have some 3.36 packages already <civodul>jonsger: setting it up requires a lot of perseverance and patience :-) 
