bug#69106: SBCL enomem on 686

2024-02-13 Thread Christopher Howard
Hi, I was trying to run SBCL on an older 32-bit laptop, using guix on foreign 
distro. When I launch SBCL, the REPL dies immediately with this error:

```
os_alloc_gc_space(1,0x900,3221225472) failed with ENOMEM
fatal error encountered in SBCL pid 4657 tid 4657:
Can't allocate 0xc000 bytes for space 1
```

However, the program does work if I pass in a --dynamic-space-size argument 
when I launch sbcl. E.g.

```
sbcl --dynamic-space-size 2000
```

So, it seems like some allocation value or define is not being set correctly in 
the build for 686. SBCL manual only says:

```
‘--dynamic-space-size MEGABYTES’
 Size of the dynamic space reserved on startup in megabytes.
 Default value is platform dependent.
```

My system information:

```
christopher@q4os-desktop 
 
OS: Debian GNU/Linux 10 (buster) i686 
Host: CF-30CTQAZBM 001 
Kernel: 4.19.0-26-686-pae 
Uptime: 21 hours, 54 mins 
Packages: 2357 (dpkg), 4 (guix-user) 
Shell: bash 5.1.16 
Resolution: 1024x768 
Terminal: /dev/pts/1 
CPU: Genuine Intel L2400 (2) @ 1.667GHz 
GPU: Intel Mobile 945GM/GMS, 943/940GML Express 
Memory: 219MiB / 3020MiB 
```

```
$ guix describe
Generation 2Feb 12 2024 12:22:05(current)
  guix bb92a4d
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: bb92a4d7bc71197a51eea9075387c5313f299085
```

-- 
📛 Christopher Howard
🚀 gemini://gem.librehacker.com
🌐 http://gem.librehacker.com

בראשית ברא אלהים את השמים ואת הארץ





bug#69106: SBCL enomem on 686

2024-02-13 Thread Christopher Howard
Just noticed, poking around in the debian sid package, that Debian had to 
explicitly set

```
export SBCL_ARCH=x86
```

For their i386 build. Wonder if that might be relevant here.

-- 
Christopher Howard





bug#69106: SBCL enomem on 686

2024-02-13 Thread Christopher Howard
Hi, the problem is with these lines:

```
 ,@(if (target-ppc32?)
 ;; 3072 is too much for this architecture.
 `("--dynamic-space-size=2048")
 `("--dynamic-space-size=3072"))
```

Package definition simply assumes that all non-ppc32 architectures can handle 
the larger dynamic space, but apparently not x86. Through experiment, I see the 
largest dynamic space that works on my old laptop is 2810, but 2048 seems like 
a more sensible number.

-- 
Christopher Howard





bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.

2024-02-13 Thread Dariqq

Hi,

On 10.02.24 04:06, Maxim Cournoyer wrote:


I have never attempted to customize gnome-shell.  If it can be
customized with custom themes, different fonts and what not, then I
think it makes sense to keep the user-choosable art assets as
gnome-shell-assets.



I tried in a vm with only gdm-service-type (and no gnome) and the assets 
also wrapped inside gdm and got a white box as a cursor. This might be 
caused by adwaita not being in the profile (which gnome-shell-assets 
also get added to) but I am not sure about this.




Otherwise, if it's not configurable and expects only a specific font,
specific icons, etc., then it seems it'd make sense that it finds them
out of the gate (wrapped from within a phase).

Could someone confirm whether GDM is configurable when it comes to icons
and fonts?

Thanks for working on it, Dariqq!



I'd suggest leaving the gnome-shell-assets as is for now and deal with 
the gdm customisation issue at another time as it looks like it is more 
complicated than just adding the assets to the wrapper.



Regarding the patch should I create and send it or someone of you? (I 
don't really care)


And if the answer is me should the patch be against master or gnome-team 
branch?


Cheers