<nckx>PotentialUser-46: Using ZFS file systems from Guix System is no problem. Kernel (module) support is there. But to actually boot from a /gnu/store on ZFS needs some basic support for reading superblocks, labels, UUIDs &c., written in Scheme.
<nckx>Guix doesn't run a mini systemd/udev/libblkid userland in the initramfs like other systems.
<Bryophyllum>jonsger: Are you aware of any plans to make it so that the system is always up-to-date on the first boot?
<jonsger>Bryophyllum: there are kind of plans that you can use installations images from current master, I think mothacehe did something into that direction
<mbakke>the installer could always be generated with 'guix system disk-image gnu/system/install.scm', but the available packages will be those from the 'guix snapshot' in gnu/packages/package-management.scm
<Bryophyllum>Is it the limitation of how Guix works that a point release ISO installer cannot effectively fetch packages from the newest commit? I see a value in not having to run `guix pull` after an update. For example, it'd solve problems caused by glibc version bumps or changes in PATH
<Bryophyllum>Right now everyone installing Guix System will have to `guix pull`, `guix build --no-substitutes nss-certs`, and then `exec bash`. These are inconveniences that I found when installing the OS using the 1.1.0 release ISO.
<Bryophyllum>Otherwise, nss-certs fails to build, and, as for the last command, it's needed to update the PATH variable, or else guix system reconfigure fails to update the system
<Bryophyllum>There's also a point of increased data transfer. Just have Guix download what will actually be needed rather than install packages from the 1.1.0 release snapshot, which will be replaced in their entirety on the first boot, assuming that a user reads the warning messages that says that guix pull should be run to avoid downgrades.
<mbakke>Bryophyllum: can you file a bug report about nss-certs failing?
<dissoc> so i wrote a package for cassandra database. what would be the directory to store the data in guix?
<dissoc>"/var/lib/cassandra" seems to match what other db services would do
<efraim>dissoc: I'd take a look at the other databases we have packaged. If you do change the localstatedir then you might need to make it not try to create /var/lib/cassandra at install and to write a service so it does the right thing
<bonz060>After switching to a different profile, I'm not supposed to be able to see packages installed in another profile(when I do a `guix package --list-installed`) right? In that case, how come after doing a: `GUIX_PROFILE="/home/bonz060/opt/test-profile" ; . "$GUIX_PROFILE"/etc/profile` I can still see packages from my default profile? Is there an extra env variable I need to set? How do you normally seamlessly switch profiles? I'd want to incorporate this to
<bonz060>my daily workflow- it sounds really convenient =)
<xelxebar>bonz060: Doing . "$GUIX_PROFILE/etc/profile" just sources that etc/profile. If you look in there, you see that it doesn't overwrite PATH but instead just prepends stuff to it.
<xelxebar>I suggest you look at guix environment --pure if you're looking for "pure" profiles.
<xelxebar>Unfortunately, guix environment doesn't have a --profile option, but you can sort of do the equivalent using an appropriate "manifest.scm"
<bonz060>xelxebar: I used guix environment --pure to create a clean profile. What I'm wondering is how "clean semantic separation of the various packages a user needs for different contexts" is achieved. I thought that if you had one profile that had, say a Python2, then you could switch to that when you are working on a legacy project. And within that profile, install every python2 deps from guix. Once you are done, you just switch out to your default profile. FYI
<bonz060>leoprikler: I'm working on a package defintion- upgrading a package to use py3- for some channel. I thought it would be easier to just test things out on a profile. From the docs, it's not really clear whether I can reuse an environment after creating it(tbh, I don't know if that's possible). Or I'm I doing things in a hacky way?
<terpri>divansantana, not that i'm aware of, beyond the official blog and planet gnu (unless you mean package updates and such, in which case, i'd say the git repo is the closest thing to an rss feed ;))
<terpri>aren't there tools for making reproducible tarballs? joey hess wrote something called pristine-tar, related to deb packaging, but i don't recall exactly what it was for
<zimoun>civodul: thank you for the pointer. I am already processing it. BTW, I have sent the patch for the new sources.json compliant with the current loader. Once merged, let keep SWH in touch and they could point their "staging" and report potential issue.
<rekado>civodul: ah, that’s an old problem that I worked around by starting the mumi web interface manually…
<rekado>I stopped the mumi service and started mumi manually and now it’s fine
<dissoc>i wrote a package for a database but i want to put the data directory in /var/lib/ . is the expectation to write a service for this? that is the impression i get from looking around
<cbaines>efraim, I'd say we have ~13400 packages currently though, if you look at the derivations you end up counting different versions of the same package multiple times, like rust contributes ~20 derivations
<efraim>guix package -A | wc -l shows closer to 13900
<efraim>guix refresh -l email@example.com says 229 dependant packages, looks like I can push the aarch64 fix directly to master
<civodul>zimoun: yeah, let's see if taking care of the original artifacts is officially a non-goal for SWH
<civodul>kinda weird because they have raw GNU tarballs for instance, on purposes AFAIK
<zimoun>civodul: yeah, I miss something... because SWHID will never be the standard over the goo'ol tarball checksum.
<zimoun>civodul: what the process for submitting an entry for the guix-hpc blog? I mean do an announcement about the Repro Hackathon?
<bonz060>In a guix environment, where do you locate installed things? And also, in a shell, how do you know you are in an environment? Like in a virtual env, the (.env) or something similar is usually displayed somewhere
<efraim>I sometimes look in $GUIX_ENVIRONMENT, like I'll check for libs in $GUIX_ENVIRONMENT/lib
<zimoun>apteryx: yes that's right. It is related to the discussion about implicit inputs we had some times ago.
<janneke>bonz060: sure, that skeleton is copied to ~/.bashrc for new guix system users
<civodul>zimoun: re guix-hpc blog, you can create an account on gitlab.inria.fr and i'll add you there
<civodul>perhaps check with Konrad what to put in there
<bonz060>janneke: thanks. I've got around to doing that. Also, I've got around to using an environment for writing packages. Now I have another question, how do you test things out inside an environment? Like is there a way to update a package inside an environment without affecting the "outside" world? Or more precisely, how do you test package definitions. Earlier, someone recommended environments over separate profile.
<zimoun>civodul: guess what my login? :-) I am created and I put my "academic" email address. Tell me if I need to accept stuff.
<janneke>bonz060: i'm not sure what you want to test, but environments cannot be changed; you can create a new environment that differs in one package or package version from another or previous environment
<zimoun>civodul: sorry to be naive, where is drafts/ ?
<civodul>ah i thought it was there, but maybe not? :-)
<apteryx>I guess I'm happy living in the present ;-)
<bonz060>janneke: I'm porting a web app that relies on packages defined in guix that use python2. Some of the deps are defined as packages with py2 packages as inputs. So I've been trying to think of an efficient way of updating the package definitions and testing it out with the web app. Right now I'm creating an environment with the required packages, and in the spawned shell, I'm using $GUIX_ENVIRONMENT/etc/profile to set the profile required by the web app.