IRC channel logs


back to list of logs

<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 won't boot.
<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.
<dadinn>anyway this is the error I got again:
<nckx>dadinn: What's mounted on /mnt?
<nckx>dadinn: You did restart the VM, right?
<dadinn>nckx: nothing, just started up the VM and ran this script:
<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 🤔
<dadinn>nckx: sorry, wrong branch: :)
<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: Absolutely
<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
<dadinn>All the malary for setting up the ZFS dkms is already supported for Debian, and Arch: ,
<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?
<dadinn>That actually sounds viable
<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
<civodul>i typically do the latter :-)
<dadinn>for some reason /tmp and /gnu/store are full... worse /tmp only has 2G: :/
<dadinn>`free` says i have 4G :/
<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?
<brettgilio>nckx: Thatll do :)
<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 :(
*nckx toasts to dadinn.
<dadinn>gave it 16G RAM, but it is now building the zfs module...
<dadinn>failed again, but not because of disk space:
<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>...vs the 5.4.52 before
<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
<dadinn>at least now we know that to build the zfs image approximately needs 6G disk space:
<hendursaga>dadinn: Pardon, I was talking about in general. I'm trying to package something rn :)
<dadinn>hendursaga: ah, sorry :P
<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.
<brettgilio>I'll look at guix discovery thanks
<brettgilio>If youre curious about the github updater crashing
<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>Here is what im trying
<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>or whatever the variable name is...
<bavier1>a grep in gnu/packages/*.scm should bring up some examples
<brettgilio>bavier1: Thank you for your genius :)
<brettgilio>I think that was all I needed
<brettgilio>it worked right after that
<brettgilio>Stay tuned, I should have 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: It's if Haskell and Prolog had a baby
<bavier1>brettgilio: do you use it?
<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 having a strange issue
<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>which, idk... looks like a string to me
<bavier1>you may need to unquote
<brettgilio>I tried that too
<apteryx>What was the error then?
<brettgilio>When I did that it says that function is undefned
<brettgilio>oh even weirder, it says Unbound variable: version-major+minor
<brettgilio>its reading it as a variable
<brettgilio>probably because im using it in a match lambda
<apteryx>brettgilio: that definition comes from (guix utils). Does your module has #:use-module (guix utils) at the top?
<brettgilio>it is indeed
<apteryx>OK, I can't say more without seeing the thing
<brettgilio>One moment
<apteryx>OK, so you unquote inside your inner list
<apteryx>but you're still inside a bigger list
<apteryx>the list of arguments
<apteryx>so you need to unquote twice I guess
<apteryx>or use (list for the inner list
<brettgilio>I tried to double unquote as well, earlier.
<brettgilio>one moment
<brettgilio>I think I figured it out
<brettgilio>Got it :)
<brettgilio>I had a lingering unquote
<apteryx>ypy! :-)
<brettgilio>thanks for your help
<brettgilio>One more thing
<brettgilio>I think I decided to go with version-prefix instead of version-major+minor
<brettgilio>,,(string-append "libatomic_ops-"
<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>which it is
<brettgilio>(version-prefix (package-version libgc) 3) in a repl works just fine too
<apteryx>more quoting issues?
<brettgilio>I guess so. I am pretty tired, but id like to figure this out before bed
<brettgilio>Here is the relevant section
<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
<brettgilio>seemed the easiest way at the time
<brettgilio>at the time was back in december tho lol
<apteryx>seems complicated for no gain
<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
<apteryx>they are indeed very similar
<brettgilio>I went with your idea to just go with the let form and remove the map
<brettgilio>which worked
<brettgilio>so problem solved :)
<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?
<NieDzejkob>c4droid: (file-exists? "/sys/firmware/efi")
<alextee[m]>sent a patch for zrythm
***PotentialUser-66 is now known as Pengu1n
<c4droid>NieDzejkob: Thanks. :)
***terpri__ is now known as terpri
<alextee[m]>anyone else missing icons in OBS studio?
*alextee[m] uploaded an image: Screenshot from 2020-07-22 09-55-44.png (49KB) < >
<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
<efraim>looks like it
<bonz060>For anyone that's free right now:
<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.
<efraim>I just ran 'mpv'
<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>but the file exists?
<jonsger>theres something wrong: /gnu/store/kb7hp2l4znyxg4aa8fhwin8m02a60sca-ispell-3.4.00/bin/ispell
<jonsger>Can't open /lib/ispell/english.hash
<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
<civodul>but Matrix looks nice
<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.
<kmicu>[Jokin’] Here’s a proof from a leaked screenshot. Notice that Ludo disconnects together with Matrix folks and joins at the same time. The Matrix Ludo Theory confirmed.
<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
<alextee[m]>^ solved, it was glu
<alextee[m]> (+ mesa)
<civodul>glu glew glu!
<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
<lfam>What goes wrong, linka?
<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
<linka>can you list the commits?
<linka>thank you
<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
<linka>kde's gonna kde
<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...
<lfam>Ah, you tried it mroh?
<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>Maybe related bug report:
<lfam>Qt report:
<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
<lfam>I'll try it
<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
<lfam>linka: I filed a bug report here: <>
***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
<alextee[m]>linka: i came from parabola too. guix is great
<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
<lfam>mbakke: Yeah...
<efraim>I sent my zram service patch just now too
<lfam>I wonder if there are any Guix Java packaging people around? I'm wondering if it's currently feasible to package sdrtrunk for Guix:
<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.
<lfam>That's awesome
<lfam>I wonder why it's laggy
<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
<jonsger>lfam: I guess
<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
<lfam>Which package?
<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>bavier: often, yes
<mbakke>I think we have some 3.36 packages already
<civodul>jonsger: setting it up requires a lot of perseverance and patience :-)
<civodul>for less verbosity: