Re: Multilib support: running 32-bit binaries on 64-bit systems
Pierre Neidhardt writes: > Guix already supports cross-compilation out of the box of 32-bit > packages on any architecture: > > guix build --system=i686-linux PACKAGES... > > Now the question is: is it possible to run the produced binaries > directly (no VM)? Yes, you can run i686 binaries directly on a x86_64 system with the default libre linux kernel (which have i686 support enabled), one example is the ‘wine’ package. > > Many other distributions have support for the so-called "multilibs", > that is, a separate 32-bit library tree with the 32-bit linker > configured to load those instead of their 64-bit counterparts. > > Does Guix have any provision for multilibs? Guix install every package into its own directory which already cover the multilibs cases.
Re: Installing GuixSD on an external USB hard drive
myg...@gmail.com writes: > On 04/16/2018 at 20:04 Divan Santana writes: > >> Hi Guix, >> >> So I'm installing GuixSD on an external USB hard drive. >> >> This is obviously quite useful to test and setup all before you switch >> to it. I plan to eventually install on laptop. >> >> I could do it in a VM but... >> >> Anyway, the install went flawless and docs are great. >> >> *After a reboot*, I did a guix pull and system reconfigure. >> >> (I did change the drive letter, since post reboot grub was on sdb, not c) > > Hi Divan, > > GuixSD is intolerant to a change in logical assignment of the boot drive > after the the "git init" ... > > Ref: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23072 > > Maybe your problem is related? Thanks! Seems similar, though I think not quite the same. -- Divan
Re: Installing GuixSD on an external USB hard drive
Chris Marusich writes: > Hi Divan! > > Thank you for taking the time to write to us about the problem. These > kinds of but reports are very helpful! Your welcome. Thanks for the great reply. > On Tue, Apr 17, 2018, 06:43 Divan Santana wrote: > >> OK, I think this is a bug. > > > It could be. Please report it to bug-g...@gnu.org. If you have an > operating system configuration file that reproduces the problem > consistently, please share it in your report. In particular, if you can > reproduce the problem using "guix system vm", it will make things much > easier for us to debug. The manual describes how to use that command: > > https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.html I need to spend time on this and try reproduce it and report it properly. For the moment I've worked around it. > > The way I worked around it was to: > > >> 1) remount /gnu/store rw >> >> 2) >> >> cd >> >> /gnu/store/n9ym4yl7s55pm57rnc5whjlzjgvxas32-linux-libre-4.16.2/lib/modules/4.16.2-gnu/kernel/drivers/usb/storage/ >> cp usb_storage.ko usb-storage.ko >> > > That's good to know, but you should not modify files in the store or mount > it rw. Absolutely. I just did it to try test the theory. I've undone the hack and will see if things break later. But this is a test system. > It can lead to unpredictable behavior because doing so may violate > certain invariants. When hacking around on a throw-away system to > investigate an issue like this, don't this might be useful, but on systems > you care about, essentially the only way you should interact with the store > is via the public Guix scheme APIs and the Guix command line tools, since > they will ensure that the store's invariants are never violated. > Again, thank you for the report! I hope everything is smooth sailing from > this point on. Thanks again. Doubt it will be smooth sailing lol. But I'm learning and guix is awesome and hope to continue learning and cotribute more in time. -- Divan
Re: Could not find bootstrap binary 'guile-2.0.9.tar.xz'
Joshua Branson writes:
> I guess I'm still a little confused. Suppose that I want to update all
> packages, on my system. The ones owned by root, and the ones owned by
> all other users. Then I'd do this?
>
> $ guix pull && guix package -u
>
> $ logout
>
> $ login DifferentUser
>
> $ guix pull && guix package -u
>
> ...repeat for all other users...
>
> $ su
>
> # guix pull && guix package -u && guix system reconfigure /etc/config.scm
>
> Does that look right?
Yes, exactly.
I should also mention that if you'd like to avoid some or all of these
'guix pull's, you can arrange for user B to always track user A's copy
of Guix like this:
ln -sf {~A,~B}/.config/guix/latest
However, manually fiddling with these symlinks is not officially
supported and might stop working in a future version of Guix. Also,
beware that if you accidentally run "guix pull" as user B, it will
overwrite the symlink, and henceforth user B will no longer track user A
until you re-run the above command.
Alternatively, if you don't want user B to _track_ user A, but you just
ran "guix pull" as user A and now you want to quickly update user B to
the same copy of Guix, you can do this:
cp -a {~A,~B}/.config/guix/latest
Mark
Re: Multilib support: running 32-bit binaries on 64-bit systems
Hi Pierre, Pierre Neidhardt writes: > Guix already supports cross-compilation out of the box of 32-bit > packages on any architecture: > > guix build --system=i686-linux PACKAGES... > > Now the question is: is it possible to run the produced binaries > directly (no VM)? Yes. > Many other distributions have support for the so-called "multilibs", > that is, a separate 32-bit library tree with the 32-bit linker > configured to load those instead of their 64-bit counterparts. > > Does Guix have any provision for multilibs? Yes, in fact Guix's support for multilibs is far more general. Guix supports not only 32-bit and 64-bit libraries on the same system, but an arbitrary number of variants of C libraries. For example, right now my x86_64 GuixSD system has one set of libraries/executables based on glibc-2.26.105-g0890d5379c (from our 'master' branch), and one set of libraries/executables based on glibc-2.27 (from our 'core-updates' branch), and I can use all of these binaries freely on the same system without any conflicts or wrappers. This works because instead of having a small ad-hoc set of global locations where a few variants of the C library, dynamic linker, etc, are stored (e.g. /lib, /lib64, etc), in Guix all of these components are stored in /gnu/store, each with a unique hash. Every executable and every library in Guix has embedded within the absolute file name of all of the components it depends on, including its dynamic linker, C library, C runtime, bourne shell, etc. Does that make sense? Mark
Re: Multilib support: running 32-bit binaries on 64-bit systems
> Does that make sense? Absolutely, but it gets trickier when trying to run a 32-bit executable which was not compiled on Guix. Any idea how to achieve that easily? The way I can think of for now is to run patchelf against the binary to change the dynamic linker path as well as the RPATH. -- Pierre Neidhardt Depart in pieces, i.e., split. signature.asc Description: PGP signature
Re: warning: could not locate elisp directory under `/gnu/store/...`
Still stuck here... Anyone? I'd love to contribute a whole bunch of Emacs packages :) -- Pierre Neidhardt There is always one thing to remember: writers are always selling somebody out. -- Joan Didion, "Slouching Towards Bethlehem" signature.asc Description: PGP signature
Re: Multilib support: running 32-bit binaries on 64-bit systems
Pierre Neidhardt writes: >> Does that make sense? > > Absolutely, but it gets trickier when trying to run a 32-bit executable > which was not compiled on Guix. > > Any idea how to achieve that easily? > > The way I can think of for now is to run patchelf against the binary to > change the dynamic linker path as well as the RPATH. This is the best approach right now. I've done this for a couple of...unsavory programs and it works okay. One alternative would be to create a 32-bit profile, and set up FHS-style symlinks for it (or a chroot). I've been thinking about adding a "--fhs" argument to `guix environment --container`, but it's still very much in the "dreaming" phase. signature.asc Description: PGP signature
Re: pcspkr only loaded after waking up from sleep
Pierre Neidhardt (2018-04-18 23:54 +0530) wrote:
> Alex Kost writes:
>
>>> (kernel-arguments '("modprobe.blacklist=pcspkr"))
>>
>> Yes, it is. I recall I also needed to blacklist "snd_pcsp" module to get
>> rid of this annoying beep (so I have "modprobe.blacklist=pcspkr,snd_pcsp");
>> although it was several years ago, maybe it is not necessary anymore.
>
> Thanks! Any idea why the module does not load properly at boot time?
Sorry, no idea :-)
--
Alex
Re: Could not find bootstrap binary 'guile-2.0.9.tar.xz'
thanks for the clarification!
Mark H Weaver writes:
> Joshua Branson writes:
>
>> I guess I'm still a little confused. Suppose that I want to update all
>> packages, on my system. The ones owned by root, and the ones owned by
>> all other users. Then I'd do this?
>>
>> $ guix pull && guix package -u
>>
>> $ logout
>>
>> $ login DifferentUser
>>
>> $ guix pull && guix package -u
>>
>> ...repeat for all other users...
>>
>> $ su
>>
>> # guix pull && guix package -u && guix system reconfigure /etc/config.scm
>>
>> Does that look right?
>
> Yes, exactly.
>
> I should also mention that if you'd like to avoid some or all of these
> 'guix pull's, you can arrange for user B to always track user A's copy
> of Guix like this:
>
> ln -sf {~A,~B}/.config/guix/latest
>
> However, manually fiddling with these symlinks is not officially
> supported and might stop working in a future version of Guix. Also,
> beware that if you accidentally run "guix pull" as user B, it will
> overwrite the symlink, and henceforth user B will no longer track user A
> until you re-run the above command.
>
> Alternatively, if you don't want user B to _track_ user A, but you just
> ran "guix pull" as user A and now you want to quickly update user B to
> the same copy of Guix, you can do this:
>
> cp -a {~A,~B}/.config/guix/latest
>
> Mark
Re: warning: could not locate elisp directory under `/gnu/store/...`
I have no idea, but keep trying! haha. By the way, it would be kind of cool if guix could package an emacs starter kit. It'd be even coolier if someone tried to use guix as the way to sell said starter kit. Pierre Neidhardt writes: > Still stuck here... Anyone? > I'd love to contribute a whole bunch of Emacs packages :)
