Tiny Core v15.0

[Juanito]

If you store your settings then manually edit asound.state to change them and then restore without rebooting do the settings change?

[Juanito]

The problem was here:

Code: [Select]

sudo alsactl store
[edit /usr/local/etc/alsa/asound.state]
sudo alsactl restore
alsa-lib parser.c:2783:(load_toplevel_config) Unable to find the top-level configuration file '/usr/local/etc/alsa/ucm2/ucm.conf'.
alsa-config adjusted and reposted

[thane]

Hi Juanito, alsa settings are still not being saved between boots. Specifically it's the 'Master' setting not being saved. It looks like asound.state file is being updated when I do "sudo alsactl store" but after I reboot, alsamixer shows the original (muted) setting is back. Don't know what to look for in the asound.state file to see if the setting was actually updated there.

Not 100% sure this is an alsa issue (maybe I'm overlooking something in the save/restore process) since the asound.state file is the only thing I'm saving/restoring other than home and opt. Anyway I can work around this for now.

Thane

[Rich]

Hi thane

... It looks like asound.state file is being updated when I do "sudo alsactl store" but after I reboot, alsamixer shows the original (muted) setting is back. ...

If you open a terminal and enter:

Code: [Select]

sudo alsactl restoredoes it throw any errors or restore the correct volume level?

[thane]

Well, this is embarrassing. Now the alsamixer settings save and restore. Since I tried it last I installed flaxpdf.tcz, gpicview.tcz, as well as evince.tcz (but deleted it later).

gpicview.tcz had a missing library error (libGLESv2) which I was going to report. Installing the libGLESv2.tcz extension fixed it, but probably a .dev file needs to be corrected.

Now I'm wondering if alsa (or alsa-config) might have a library issue too that one of the installs inadvertently corrected.

Sheesh.

thane

[Juanito]

gpicview.tcz had a missing library error (libGLESv2) which I was going to report. Installing the libGLESv2.tcz extension fixed it, but probably a .dev file needs to be corrected.

cairo used to have a dep on libGLESv2, which masked the gtk2 dep on libGLESv2 - gtk2 dep file adjusted.

Now I'm wondering if alsa (or alsa-config) might have a library issue too that one of the installs inadvertently corrected.

You would see an error message if that were the case.

[thane]

Hi Juanito, I agree about the error message, but it bothers me a bit when problems seem to fix themselves! Reverse cosmic rays...

Thanks to you and Rich for the help!

thane

[patrikg]

See what i found on the web:

https://youtu.be/206f7nX4IGo

[Rich]

Hi curaga
I know it's too late for this version, but I wonder if there's
any reason not to include a  /lib64->/lib  link in the x86_64
rootfs64.gz.

firefox_getLatest.tcz includes a command in the tce.installed
file for firefox to create that link.

This is a partial list of problems forum members had due
to /lib64 not being present:
https://forum.tinycorelinux.net/index.php/topic,21993.msg173865.html#msg173865
https://forum.tinycorelinux.net/index.php/topic,26512.msg171207.html#msg171207
https://forum.tinycorelinux.net/index.php/topic,26326.msg169980.html#msg169980
https://forum.tinycorelinux.net/index.php/topic,26342.msg169821.html#msg169821
https://forum.tinycorelinux.net/index.php/topic,26113.msg167596.html#msg167596
https://forum.tinycorelinux.net/index.php/topic,25633.msg164427.html#msg164427

[curaga]

It's just a matter of style. lib64 is ugly, and only required by external binaries. If you'd like to have it in, fine by me.

[Juanito]

Perhaps because some distros are moving to 64bit only, less external binaries seem to require the symlink.

There's also the (small) risk that, if the symlink is included in the base, source compiled on tinycore will link against /lib64/ld-linux-x86-64.so.2

[Rich]

Hi Juanito
Thanks for the info. Leave it the way it is then.

[andyj]

There's also the (small) risk that, if the symlink is included in the base, source compiled on tinycore will link against /lib64/ld-linux-x86-64.so.2

This would be my concern. I get that it's a problem for some apps not compiled on TC, but is that really our problem? It seems like a tar pit that will just bring in other problems. If an external app needs the loader in /lib64 instead of /lib, there should be a script in the extension's tce.installed directory to take care of it then. At least that's how I've handled apps like Google Earth and Chrome.

[nurbles]

Is there any (easy, I hope!) way to get the version number for all of the TCZ packages?  I've been given a list of CVE numbers and I need to ensure that none of them reference packages we will be using in TinyCore.  I looked at http://tinycorelinux.net/15.x/x86/tcz/, but (for example) the only zlib mention there is "zlib_base-dev.tcz", which doesn't show me that zlib is v1.3, which is what I need.

I thought the tcz link in the sources would've taken me to the tcz sources (which would have the version info), but it just displayed the text file listing all the tcz names.

[Juanito]

http://www.tinycorelinux.net/15.x/x86/tcz/zlib_base-dev.tcz.info shows the version number is 1.3?