Re: Thoughtful updates to TexLive
Hello, Andreas Enge writes: > Actually I am wrong, it is CTAN, not Texlive. And CTAN contains rather > obscure packages, such as the thesis format for this or that university, > which I suppose are not shipped as part of Texlive. I believe TeX Live includes all free parts of CTAN. In particular, texlive-collection-publishers is full of these thesis formats. Regards, -- Nicolas Goaziou
Re: chez scheme can't load system shared library
Dear André, yours and Pan message suggest you are using guix on a foreign distro. That would also mean, that the libraries you find in /usr/lib are the ones from the foreign system. As such, these libraries will have been compiled+linked with different tools/versions than the ones in guix. I believe this makes them incompatible and leads to the dreaded "Segmentation fault" error. I know no solution to mix+match libraries from guix with those of your distro. It seems really all or nothing. Hope this clears things up, Sebastian On 3/26/25 10:51, guix-devel-requ...@gnu.org wrote: Date: Wed, 26 Mar 2025 10:23:19 +0200 From: André A. Gomes To: Pan Xie Cc: Felix Lechner,help-g...@gnu.org, guix-devel@gnu.org Subject: Re: chez scheme can't load system shared library Message-ID:<871pukurns@gmail.com> Content-Type: text/plain; charset=utf-8 Pan Xie writes: Thanks for your response. Unfortunately, it does not work: `LD_LIBRARY_PATH' is empty in my shell: $ echo $LD_LIBRARY_PATH scheme can't start up with LD_LIBRARY_PATH set: $ LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH scheme Segmentation fault (core dumped) $ LD_LIBRARY_PATH='/usr/lib' scheme Segmentation fault (core dumped) The question by Pan has been answered but I have questions on this topic: What's the cause of this segmentation fault on Guix? Is there a way to use chez scheme installed via Guix to see the shared library at /usr/lib (instead of installing the package that provides it it via Guix)? Thanks. -- André A. Gomes "You cannot even find the ruins..."
Re: New procedure to modify operating-system records
Hi Sergio, Sergio Pastor Pérez writes: > Rutherther writes: >> what I am asking is how this will be achieved - coverage of same use >> case. Possibly I am just missing something, so let's take guix system >> reconfigure as an example. Could you point where I am wrong in my >> reasoning? >> >> 1. Guix system reconfigure expects a file as argument, that will return >> operating-system record. >> 2. with-transformation uses map-derivation, it will work on >> operating-system-derivation, not on operating-system, and >> return a derivation, not an operating-system. >> 3. Therefore, without changes to guix system reconfigure, it cannot be used >> as the returned object from file is not operating-system. > > Yes, you are correct. I'm not sure if `guix system reconfigure' accepts > a derivation. If it does not, we will have to adapt it. > > It would make sense that reconfigure accepted a derivation since > `guix build' does. For example the following file it's valid for > `guix build -f `: It doesn't. And I don't think it will be easy to make the whole guix system stuff work with raw derivations. The thing is, the derivation being built changes according to the action, the vm and container have a different derivation than the one used with reconfigure. On top of that, and probably more importantly, the operating system fields are utilized for various checks or even for installation, ie. the bootloader is taken out of operating-sytem-bootloader, not from the operating system derivation (I think the operating-system-derivation doesn't even depend on the bootloader at all), and maybe even more stuff I am missing. If we were to talk about the easiest approach, I think that the easiest would be to make an operating system field like `transformation` that would get applied when the derivation is being lowered[1] in the system script. Additionally, guix system doesn't currently handle regular guix transformations, the same could be done about those to start supporting it with guix system. The only questionable thing is, then, what all derivations should be transformed, if only the operating system itself or also the bootloader, vm (qemu...) etc. [1] See guix/scripts/system.scm (system-derivation-for-action) Regards, Rutherther
Re: Guix on the MNT/Reform Status Update
Hello Vagrant, Am Sun, Mar 23, 2025 at 04:54:15PM -0700 schrieb Vagrant Cascadian: > Tested on MNT Reform2 with rk3588 module (other variants *might* work too!) I own an original Reform with the imx8mq module (I think), and the other day came upon a special offer for an SD card in my local supermarket, so I could go ahead and give it a try; but I would need a detailed description for dummies on how to create a boot image, as I have only very vague ideas how booting works in general and outside of grub in particular. Right now I boot from an SD card and have "everything else" on the encrypted NVME SSD (/boot is SD, / is SSD), so I suppose it would be easily possible to boot from a Guix SD as / without using the SSD. Would you mind sending me a configuration file and line-by-line instructions on what to do? I suppose it is a "guix system image" followed by a "dd" to the SD card? Hm, but where would the uboot come from then? Thanks for your help! Andreas
Re: chez scheme can't load system shared library
Not sure how to answer to a particular meesage from the digest emals I am receiving. Hope this finds the right person and thus not upset anyone. Hi Pan, you need to set LD_LIBRARY_PATH to your profile library path (and then load without absolute path in chez). The following works for me: > guix shell -CP coreutils-minimal chez-scheme openssl > ls ~/.guix-profile/lib csv10.1.0 engines-3 libcrypto.so libcrypto.so.3 libssl.so libssl.so.3 ossl-modules pkgconfig > LD_LIBRARY_PATH=~/.guix-profile/lib scheme (load-shared-object "libssl.so") Best Sebastian
Re: chez scheme can't load system shared library
Pan Xie writes: > Thanks for your response. Unfortunately, it does not work: > > > `LD_LIBRARY_PATH' is empty in my shell: > > $ echo $LD_LIBRARY_PATH > > > scheme can't start up with LD_LIBRARY_PATH set: > > $ LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH scheme > Segmentation fault (core dumped) > > $ LD_LIBRARY_PATH='/usr/lib' scheme > Segmentation fault (core dumped) The question by Pan has been answered but I have questions on this topic: What's the cause of this segmentation fault on Guix? Is there a way to use chez scheme installed via Guix to see the shared library at /usr/lib (instead of installing the package that provides it it via Guix)? Thanks. -- André A. Gomes "You cannot even find the ruins..."
Re: chez scheme can't load system shared library
André A. Gomes writes: Pan Xie writes: scheme can't start up with LD_LIBRARY_PATH set: $ LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH scheme Segmentation fault (core dumped) $ LD_LIBRARY_PATH='/usr/lib' scheme Segmentation fault (core dumped) The question by Pan has been answered but I have questions on this topic: What's the cause of this segmentation fault on Guix? Is there a way to use chez scheme installed via Guix to see the shared library at /usr/lib (instead of installing the package that provides it it via Guix)? Generally, this is not possible. It's not a problem that's limited to Guix. You cannot generally assume that libraries from different sources are ABI compatible. Segfaults like this are often the result of forcibly joining binaries with incompatible ABIs. The ABI is a contract between different binaries that allows one binary to jump straight into some offset of a library to execute instructions. When that contract is broken or ignored (because the binaries disagree on the offsets of the implementation of a named feature) then an executable may jump into the void where it expected a library to provide an implementation. This jump into the void is punished by the kernel with termination of the executable. LD_LIBRARY_PATH is a very blunt tool and it is meant for people who know for a fact that the libraries contained in the given directories implement a compatible ABI as the given executable. On traditional systems with a single global store of compatible libraries built with the same toolchain and linked with the same set of "system" libraries throughout this assumption generally holds. When more than one toolchain is used, however, all bets are off. -- Ricardo
