Core v17.0beta1

[Juanito]

Team Tiny Core is pleased to announce that Tiny Core 17.0 Beta1 is available for public testing:

http://repo.tinycorelinux.net/17.x/x86/release_candidates/distribution_files
http://repo.tinycorelinux.net/17.x/x86_64/release_candidates/distribution_files

This is an beta level cut. If you decide to help test, then please test carefully. We don't want anyone to lose data.

We appreciate testing and feedback.

Changelog for 17.0 beta1:
* kernel updated to 6.18.2
* glibc updated to 2.42
* gcc updated to 15.2.0
* binutils updated to 2.45.1
* e2fsprogs base libs/apps updated to 1.47.3
* util-linux base libs/apps updated to 2.41.2

* provides.sh: Update scripts to work with https mirrors from mbartlett21
* tce-update: Undo changes around fetchzsync from mbartlett21
* tc-functions: Update https checking from mbartlett21
* tc-functions: Change subshell from mbartlett21
* update-everything: Add /usr/local/bin to PATH from mbartlett21
* shutdown.sh: handle empty lines in /opt/.xfiletool.lst from mbartlett21
* 50-udev-default.rules: expanded input device permissions from bdantas

[aus9]

this is question on a TCE if I look at
http://tinycorelinux.net/17.x/x86_64/tcz/glibc_add_lib.tcz.list

SNIP
/lib/libmvec.so.1
SNIP
/usr/lib/libmvec.so

I am not sure the sym link is working correctly. Feel free to correct my inference

Code: [Select]

ls -al  /usr/lib/libmvec.so
lrwxrwxrwx 1 root root 44 Jan 25 21:20 /usr/lib/libmvec.so -> /tmp/tcloop/glibc_add_lib/usr/lib/libmvec.so

tc@box:/tmp/tcloop/glibc_add_lib/usr/lib$ ls -al libmvec.so
lrwxrwxrwx 1 root root 22 Dec 11 19:43 libmvec.so -> ../../lib/libmvec.so.1
tc@box:/tmp/tcloop/glibc_add_lib/usr/lib$ ls ../../lib/libmvec.so.1
../../lib/libmvec.so.1

# the real file
ls -al /lib/libmvec.so.1
lrwxrwxrwx 1 root root 42 Jan 25 21:20 /lib/libmvec.so.1 -> /tmp/tcloop/glibc_add_lib/lib/libmvec.so.1

submitqc is not seeing it a sym link...it claims that even though I have glibc_add_lib.tcz in the dep file
submitqc is still reporting I am missing libmvec.so.1
I am suggesting we have too many sym links ...that is the real file in ram drive is a sym link and then you have a sym link to a sym link. Maybe an install script to resolve?

thanks for reading

[Juanito]

For me that's the correct way to do things - i.e. the symlink is relative:

Code: [Select]

/tmp/tcloop/glibc_add_lib/usr/lib$ ls -l libmvec.so
..libmvec.so -> ../../lib/libmvec.so.1
Maybe a problem with submitqc?

[Rich]

Hi aus9
Is this what you think is a problem:

...

Code: [Select]

----- Snip -----
tc@box:/tmp/tcloop/glibc_add_lib/usr/lib$ ls ../../lib/libmvec.so.1
../../lib/libmvec.so.1
 ----- Snip ----- ...

That's not a link. You prepended a relative path (../../) to the file name
you are looking for:

Code: [Select]

tc@box:~$ cd /usr/local/lib
# The relative path used in the  ls  command gets prepended to the result.
tc@box:/usr/local/lib$ ls ../../../lib/ld-linux-x86-64.so.2
../../../lib/ld-linux-x86-64.so.2

# Walk up the path and repeat
tc@box:/usr/local/lib$ cd ..
tc@box:/usr/local$ ls ../../lib/ld-linux-x86-64.so.2
../../lib/ld-linux-x86-64.so.2

tc@box:/usr/local$ cd ..
tc@box:/usr$ ls ../lib/ld-linux-x86-64.so.2
../lib/ld-linux-x86-64.so.2

# Even the forward slash gets prepended if included in the command.
tc@box:/usr$ cd ..
tc@box:/$ ls /lib/ld-linux-x86-64.so.2
/lib/ld-linux-x86-64.so.2

tc@box:/$ ls lib/ld-linux-x86-64.so.2
lib/ld-linux-x86-64.so.2
tc@box:/$

[andyj]

Any headway on xf86-video-vmware.tcz for 32-bit?

Also, what is the -s option for /usr/bin/version for? It currently returns the same as -l and default.

If it was

Code: [Select]

s) echo "${RESULTS%%-*}" instead of

Code: [Select]

s) echo "${RESULTS##*_}" it would return just the major.minor version. Apparently it is meant for something else?

[Juanito]

Any headway on xf86-video-vmware.tcz for 32-bit?

It was posted yesterday or the day before in the 16.x and 17.x repos

[aus9]

@Juanito
If interested ....had my first and so far only lock up during boot up on x86_64. I was in a bit of rush (yes my defining character   but took a screenshot - rebooted and it failed to re-appear. Only then thinking maybe I should log it. Last few lines seem to be udev trying to settle an usb trackball with a certain brand.
image expires in 2 days. Yes I should have made it wider and then zoomed
https://i.postimg.cc/brPDzzW4/IMG-20260126-172107.png

[andyj]

Code: [Select]

tc@box:~$ version           
17.0-beta1


It was posted yesterday or the day before in the 16.x and 17.x repos

I don't know why, but tce-update thinks my system is up-to-date and I still don't have the latest vmware_drv.so.

[Rich]

Hi andyj

... I don't know why, but tce-update thinks my system is up-to-date and I still don't have the latest vmware_drv.so.

I just checked the 32 bit TC16 and TC17 repos. They show that
xf86-video-vmware.tcz was last updated on the 24th.

I checked the MD5 against the .md5.txt file in case the .md5.txt file
was a stale copy, but the 2 matched.

The current xf86-video-vmware.tcz.md5.txt is:

Code: [Select]

e8fa69cd1cdd1e6793bd895d18264a35  xf86-video-vmware.tcz
You aren't missing xf86-video-vmware.tcz.md5.txt by any chance. That
would cause the update to ignore xf86-video-vmware.tcz.

[andyj]

You aren't missing xf86-video-vmware.tcz.md5.txt by any chance.

That was it, fixed. The vmware_drv.so works, and unlike 64-bit, it works correctly after cycling through the monitors. I still think the 64-bit problem is an FLWM problem, but I can't prove it yet.

The 32-bit kernel is still doing this occasionally doing this on shutdown:

Code: [Select]

[  269.732658] EXT4-fs (sda1): unmounting filesystem 7e0105f6-901c-47b1-ae1d-d65be1a82a4c.
[  269.733797] EXT4-fs (sda1): Inode 1 (a538b8c0): inode tracked as orphan!
...and...
[  269.762345] EXT4-fs (sdb1): unmounting filesystem 1df63ddf-4e55-43f3-940c-5696f16aa53b.
[  269.773614] EXT4-fs (sdb1): Inode 1 (20fffd94): inode tracked as orphan!
But the disks are clean on reboot.

[Juanito]

I still think the 64-bit problem is an FLWM problem, but I can't prove it yet.

It's possible - in the x86 repo flwm is built against fltk-1.3, which supports x11 only. In the x86_64 repo flwm is built against fltk-1.4, which supports wayland and x11.

[Rich]

Hi andyj

... and unlike 64-bit, it works correctly after cycling through the monitors. I still think the 64-bit problem is an FLWM problem, but I can't prove it yet. ...

I would think Xorg sets the screen resolution, not FLWM.

There is one new feature in FLWM that may be coming into play:

... What does this mean?  The biggest difference is that FLTK 1.3 does not support built-in fractional scaling of GUI applications, so you can't zoom the size of Fluff in the 32-bit version like you can the 64-bit version, ...

Does your environment include  FLTK_SCALING_FACTOR=  being exported?
What is the  Xft.dpi  setting in .Xdefaults? See:
https://forum.tinycorelinux.net/index.php/topic,27517.msg177719.html#msg177719

[andyj]

The issue I'm having with 64-bit FLWM doesn't have anything to do with scaling. The scaling never changes when resizing the window, it's the virtual display resolution that changes. Everything looks right, I don't see anything not drawn right or other artifacts. The issue is after cycling in 64-bit, when a new window is opened, generally using wbar, instead of opening in the upper left at 0,0 it opens in the middle of the screen. 32-bit doesn't do this, it continues to open at 0,0 as before.

[CNK]

Core 17.0beta1 boots fine on my AM486DX2-66 PC with 20MB RAM (HDD install).

Stories of Linux's 486 support being removed already have been greatly exaggerated!

[CNK]

Core v17.0beta1 also boots on my HP 2533t with its VIA C7-M CPU, which didn't work with TC16.

It does still need "acpi=off" on the kernel command line or it reboots during start-up.

I tried this lock-up test script and it completes without issue too. So it seems the VIA C7 lock-up problem is fixed, whatever it was that caused it before.