<iskarian>"CONFIG_X86_X32: Include code to run binaries for the x32 native 32-bit ABI for 64-bit processors. An x32 process gets access to the full 64-bit register file and wide data path while leaving pointers at 32 bits for smaller memory footprint. You will need a recent binutils (2.22 or later) with elf32_x86_64 support enabled to compile a kernel with this option set."
<iskarian>it looks like we've been building the kernel with this for a while, though
<apteryx>yeah, I don't get why we get the warning, binutils should be available (which version though?)
<Guest53>I have had some decent success with Cuirass for my personal project, I have a bunch of questions however. I couldn't get cuirass version currently shipped with guix running well (it errors out with an mkdir problem, upon evaluating a specification). So I had to go with 'guix environment cuirass' with whatever was in the git repository and that
<Guest53>worked better. The web interface is a little bizarre, with some of the links not working (where I can't see the raw log).
<b3>Hi, has anyone had success running X as a regular user without a display manager? I thought it would be as simple as using the `xorg-server-service-type` service within my configuration and installing the `sx` package, but when I run `sx` my input devices don't work and in the Xorg log there's a lot of permission denied errors
<dhruvin>Oh yes, I could specify all bashrc configuration in one place, i.e. in home-bash-service-type's home-bash-configuration itself.
<dhruvin>I was trying to organize it in a different way. Each package I use will have one service, which will extend home-files-service-type, to populate configuration files for that package and home-bash-service-type to alter bash[rc|_profile]. But I believe I will go with the way you have suggested for the time being.
<bonz060>I'm trying to run redis in a container; and to interact with it from outside the container...
<jpoiret>if you just do `guix container exec PID /bin/sh` do you get a shell?
<bonz060>jpoiret: yup. Though it's the shell from the system; not the container (I think)
<jpoiret>why do you think you'd be able to get something by echoing $GUIX_ENVIRONMENT though?
<jpoiret>if your PID1 is redis-server, no guix env variables should be ever set up, right?
<jpoiret>does `pstree` show that shell as running under the redis-server?
<jpoiret>in guix, env variables are mostly setup through /etc/profile sourcing and the like (xinitrc for graphical sessions), which doesn't happen here
<bonz060>jpoiret: My (layman's) interpretation of "Execute a command within the context of a running container) is that running a command would be akin to be doing so from within a container...
<jpoiret>yes, i understand, but inside the container, the env variable GUIX_ENVIRONMENT isn't set
<jpoiret>if you use the --link-profile option of guix environment --container, you should be able to have echo $GUIX_ENVIRONMENT output something (make sure you're not in a directory where .guix-profile already exists though)
<bonz060>jpoiret: I still get a blank. I don't think it works how I intend it to work. I reckon I'll just run everything inside a container in one swoop instead of having to interact with that container from outside...
<jpoiret>bonz060: if you guix container exec PID ps -aux, do you see all the host processes or just the container's view of it?
<abrenon>first, if you've tested many configurations in the begining, adding and removing software as you made yourself comfy, you may have many older system *generations* around
<abrenon>these take some space because guix allows you to revert back to any of them (they show up in grub's menu, and you can list them with guix system list-generations)
<abrenon>once you've decided which you didn't need any longer, you can use guix system delete-generations on them
<abrenon>this will only tell guix it can stop caring, and they become elligible for garbage collection, which is triggered separately by calling guix gc
<abrenon>you may want to update your system before that
<abrenon>because updating sometimes requires pulling temporary dependencies, for instance if the packages you need aren't available or if there is some content that needs to be generated with tools you haven't explicitely requested in your environment
<abrenon>(I think I've seen one package using pandoc to output some documentation, for instance, so if you didn't specify pandoc to be installed, it would be removed by gc, but pulled again when you update… so if you're going to do a little bit of cleaning and you can still afford the space, you probably want to upgrade first)
<tricon>I have a machine manifest for use with guix deploy. After a successfuly deployment, if I only change the IP address in static-networking-service and redeploy, the networking-* service for the given interface is not restarted in order to affect the new IP address. Is this expected behavior?
<civodul>tricon: hi! it's expected in the sense that restarting it would restart services that depend on it, which may or may not be what you want
<tricon>civodul: I had a feeling that would be the case, which makes sense. I read through a mailing list thread re: such. Is there a recommended way to restart the service? Good ol' ssh + command?
<civodul>roptat: yes, i was pretty sure that'd be the case :-)
<attila_lendvai>is anyone here by any chance familiar with the updating of the bootstrap binary guile in guix? it's very old (2.0.9), and it lacks something i wanted to use. if it's simple enough, i'd appreciate if someone would do it. details in: http://issues.guix.gnu.org/50878#4
<civodul>attila_lendvai: hey :-) like i wrote on #bootstrappable, we probably won't update the bootstrap Guile
<civodul>mostly because we try not to change those big binary seeds, because they're opaque
<abrenon>roptat: does that mean more untranslated strings added to weblate ?
<jpoiret>anyone experienced with the cargo build system? i'm building rust-bitflags and it seems that it is searching for Cargo.toml in the root of the build dir, whereas it seems to be unpacked in guix-vendor/rust-bitflags-***.crate
<apteryx>nckx: oh, neat! Yeah it takes age because it builds without -j
<apteryx>we should fix that (I opened a bug about it)
<Jeremy[m]>(I'm reading through the manual in an attempt to understand Guix better)
<robin>guixy is gone for now but i'm not so much concerned about documentation size as cluttering the info dir. it's been a while but i think e.g. debian just has a single "libc" menu item for the manual
<rekado_>robin: more power to you! I’d love to see a Guile-based mcclim!
<rekado_>I was on a bad Wifi today and now something has cached failed hostname lookups.
<rekado_>I tried “sudo herd invalidate nscd”, but icecat still tells me it can’t find the domain.
<rekado_>(also restarted nscd and icecat, but to no avail)
<radvendii>ah, okay, thanks. yeah i was using the wrong term
<rekado_>hmm, on core-updates-frozen the problem with building gnumach is exactly the same as the problem I had building 389-ds-base
<rekado_>it’s a linker problem that looks like this: ld: libkernel.a(io_perm.o):/tmp/guix-build-gnumach-1.8-1.097f9cf.drv-0/source/./kern/cpu_number.h:34: multiple definition of `master_cpu'; libkernel.a(model_dep.o):/tmp/guix-build-gnumach-1.8-1.097f9cf.drv-0/source/./kern/cpu_number.h:34: first defined here