Tiny Core 10.0 Alpha 2 Testing

[Juanito]

Could you propose a patch?

[andyj]

Here's a patch. This is the behavior I don't understand:

Code: [Select]

tc@box:~$ localedef --list
en_US.utf8
tc@box:~$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
tc@box:~$ locale -a
C
en_US.utf8
POSIX
tc@box:~$

Why are all the LC_* variables set but not LC_ALL and where does this happen?

Regarding php/pspell, thanks for the update. Unfortunately it didn't fix the futex hang in the pspell_check function. I tried changing gcc optimization to -O2 instead of -Os, but that didn't help.

[Juanito]

I recall reading somewhere that $LC_ALL (and $LANGUAGE) being unset was the default behavior in order to allow the other $LC_* settings to be overridden without having to change them all?

[andyj]

That seems reasonable and I don't doubt it based on what I was able to find. As far as I know perl is the only thing complaining, and I'm only using perl because some of the "make test" are written in perl and the language setting doesn't seem to affect the test outcomes. I personally have no desire to use perl, so if you choose not to accept the patch I'm fine with that. The multiple language variables does seem to be the result of cruft from a lot of packages and lack of early standardization. But, a line exporting LC_ALL in /etc/profile when it's not being set anywhere seems like cruft too. It seems like if we're going to export it then we should set it, or if we're not going to set it then don't export it.

[Juanito]

I did a bit of checking and found this in the debian wiki locale section:

Warning - Using LC_ALL is strongly discouraged as it overrides everything. Please use it only when testing and never set it in a startup file

..anyway, it's good your question prompted some thought on the subject.

[andyj]

While poking through the kernel config I noticed that "CONFIG_HOTPLUG_CPU=y", but "# CONFIG_MEMORY_HOTPLUG is not set". Granted that both of these are probably just for VM's, but it does seem that if we have one we should probably have the other.

[curaga]

VMs usually use the balloon drivers to dynamically adjust RAM.

[andyj]

As far as I can tell, ballooning is meant to recover RAM in an overcommit situation. If I increase the ram for a VM from 4 to 8 GB for instance and I'm still not overcommitted, I'll have to reboot for the VM to see it because the kernel isn't hot-add-memory capable. This isn't a ballooning situation.

[andyj]

I've determined that the problems with php-pspell began when aspell was recompiled against ncursesw. When I load the old aspell the tests don't hang. What other compile options for aspell were used?

[Juanito]

see:

http://www.tinycorelinux.net/10.x/x86_64/tcz/src/aspell/compile_aspell
http://www.tinycorelinux.net/9.x/x86_64/tcz/src/aspell/compile_aspell
http://www.tinycorelinux.net/5.x/x86_64/tcz/src/aspell/compile_aspell

[curaga]

Yes, ballooning requires you to set it in advance. You might set "use 2GB right now, but 8GB max". Hotplug would be required for the case you showed.

[andyj]

Ballooning for VMware at least is a server feature. I don't know that it is supported in workstation, but workstation will let me add memory.

For aspell, by trial and error I found that adding --enable-compile-in-filters to configure it works with php. Of course that begs the question, what about loading filters causes it to hang?