<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
<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>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
<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.