Tiny Core Linux
Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: Juanito on March 01, 2025, 06:31:33 AM
-
Team Tiny Core is pleased to announce that Tiny Core 16.0 Beta1 is available for public testing:
http://repo.tinycorelinux.net/16.x/x86/release_candidates/distribution_files
http://repo.tinycorelinux.net/16.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 16.0 alpha1:
* kernel updated to 6.12.11
* glibc updated to 2.40
* gcc updated to 14.2.0
* binutils updated to 2.43.1
* e2fsprogs base libs/apps updated to 1.47.1
* util-linux base libs/apps updated to 2.40.2
* zlib base lib updated to 1.3.1
* getTime.sh: support more than one server from dhcp from miesi-ionos
* update-everything: offer to remove deprecated extensions from bdantas
* tc-function remove mount/umount from bb list from CardealRusso
* provides.sh: Rich's improved versions: update from CardealRusso
* linuxrc: remove symlink from GNUser
* update-everything: backup stale .dep files form bdantas
Not in the base, but also updated:
* mirrorpicker: grab info.lst from 15.x
* mirrorpicker: explicitly use bb wget
* editor: various changes from Rich
Note also that the fltk_projects in x86_64 have been updated to use fltk-1.4 with x11 and wayland. In the interests of minimising bloat the x86 fltk_projects remain with fltk-1.3 x11 only.
-
I've updated to the RC release. The attached screenshot is with my current build of FLWM_topside. The window management buttons are on the left rather than right because the new fractional scaling of FLTK 1.4 is tricky to implement for the frame (window "decoration") because the X11 functions deal in coordinates with in real pixel values whereas FLTK mostly works in it's scaled coordinates (which works great for the application window contents, but is tricky for placing elements relative to the border). The titlebar characters are scaled up in a way that is proportional to the FLTK fractional scaling factor, which the FLTK library will determine from the Xdefaults Xft.dpi setting (probably the preferred way, since it works with other WMs) or an explicit FLTK_SCALING_FACTOR environment variable, if defined. I'm not certain the title is scaled exactly right. I'll get an image viewer that lets me count pixels more easily and work that out.
Even if this window button placement is OK, there's several other issues with my custom build of FLWM I've noticed:
1) The pop-up menu is missing the sub-menus for applications and system commands ... this is probably just a temporary issue in my custom build!
2) The window resizing method of dragging on the window border only works on the top edge (to change height) and upper left corner (height and width). This is not very workable due to the next issue...
3) Windows that are large are often placed where their titlebar and left edge is just off-screen, so I cannot grab the resize corner
4) Mouse cursor jumps to odd locations sometimes
I will try the standard RC build of FLWM in a few minutes. Maybe it is mostly OK and the full release of TC 16 can just go with that.
-
Update with the standard RC build of flwm...
1) is not an issue, the popup menu has all three submenus (Applications, OnDemand, SystemTools); I'll need to sort that out in my custom build :-[
2) same challenges to window resizing exist... it would be much nicer for all users to be able to resize from any edge or corner, I'd say
3) does not seem to be an issue
4) have not noticed, but I have not tested very long
HOWEVER, if one sets up the fractional scaling in .Xdefaults with Xft.dpi set to something much above 96.0 (e.g. 128.0 for 133%, or 144.0 for 150% scaling, the 'iconize' button will disappear that should be placed in the lower left corner of the standard FLWM window frames with the titlebar on left. I think this is fundamentally the same issue I was having with the 'topside' button placement... the scaled coordinate is too big to be visible in the clipping rectangle's pixel coordinates. Basically, the button placement code needs to un-do the default fractional scaling of the FLTK library when positioning buttons at the limits of the window to the right and/or bottom.
Note: this iconize button disappearing issue does not occur if one sets the .Xdefaults value of Xft.dpi to 96.0 (100%) and then manually scales up any specific window with the scaling hotkey (Ctrl + Shift + EqualsKey (i.e. a Plus), or if your FLTK prefs have SimpleZoomShortcut set to 1, you can just use Ctrl + EqualsKey ).
-
Hi MikeLockmoore
... 2) same challenges to window resizing exist... it would be much nicer for all users to be able to resize from any edge or corner ...
As long as I can remember, FLWM_topside allowed resizing from
the top, right, and bottom edges as well as all 4 corners. The
left edge was never an option, which is fine by me.
... if one sets up the fractional scaling in .Xdefaults with Xft.dpi set to something ...
Since FLTK provides user controlled scaling, one should not interfere
with it (in my opinion) by messing with the systems DPI setting.
-
... if one sets up the fractional scaling in .Xdefaults with Xft.dpi set to something ...
Since FLTK provides user controlled scaling, one should not interfere
with it (in my opinion) by messing with the systems DPI setting.
If you look in the FLTK documentation, it uses this setting to define the initial scaling factor:
Display Scaling Factor
FLTK uses the value of the Xft.dpi resource divided by 96. to initialize the display scaling factor. That is also what is done by the gnome and KDE desktops.
Users who want the apps scaled consistently and don't want to manually adjust every application should be able to set this value and the WM handle it in a reasonable way, IMO. I don't think it is rocket science to fix this... I just need to understand what is scaled versus what remains unscaled, then make it all fit together correctly.
-
Getting closer to the non-scaled version while supporting Xft.dpi setting. At this DPI setting, the titlebar window management buttons are getting clipped a bit, and the size of the button is not leaving much room in very narrow windows for the app title (eg. MountTool). I'll work on this some more in coming days. I think I could be over-scaling the titlebar font, which is also making the buttons bigger than needed. --Mike
UPDATE: Definitely making the title font too big. In the screenshot, the normal app menu font is 16 pixels high, but the title is 19 pixels high. This was with a dpi setting of 144.0 (144/96 = 1.5, so 150% of normal scaling).
Another minor issue observed: in the wbar, causing the rightmost icon to zoom with the mouse-over motion leaves a small amount of background visual noise, maybe 8 pixels high by several pixels wide (it moves around a bit for me). Not sure if I can catch in a screenshot. I think this was happening with the dpi setting of 144 (for the above test).
-
Hi MikeLockmoore
... Not sure if I can catch in a screenshot. I think this was happening with the dpi setting of 144 (for the above test).
Open a terminal and type:
screenshot.shthen move the mouse cursor over the wbar. When you see the
"background visual noise", hit the enter key. Since the terminal
still has focus, you should get a screenshot.
-
This isn't really specific to the version 16 beta but, since the fltk applets are in the discussion..
I've always found it inconvenient that when I open "apps" and I want to see the list of extensions in the repo (which is the only reason i open "apps"), I have to click the "Apps" button, slide down to the resulting menu, keep the mouse pointer on "Cloud (Remote)" while sliding over to the submenu then select and click on "Browse". This is cumbersome using a mouse and even more so using a touchpad.
I know other people's use cases might be different, but I almost never open the apps utility that i don't want to see that list of extensions in the repo and I never use any repo other than the default.
Would it be possible (or even desirable to other users) to have a browse button on the main apps screen? Or even maybe just move "browse" to the first menu under the "Apps" button? Or just have apps get the list of extensions on startup?
-
As it also does ondemand and onboot management, which may be used offline, automatically fetching would be inconvenient to some users. Menu reorg, not opposed.
-
Hi curaga
Menu reorganization looks straight forward. Maybe something like:
Browse
Mirror Options -----> Select Mirror
|
---> Select fastest mirror
Load App Locally
Maintenance >
Installation Options >
Quit
-
Thanks guys. I figured the auto fetching would not be the best - only mentioned it because I thought it might be the simplest code change.
-
Hi Leee
How about this:
(https://forum.tinycorelinux.net/index.php?action=dlattach;topic=27550.0;attach=7014)
-
Big thumbs up on that. I think that will make it much smoother, especially when using a touchpad (which I try not to do but too often end up doing anyway).
-
I wanted to let people know that I've made some nice progress at making the FLWM work better with the fractional scaling (High DPI) functionality of FLTK 1.4, especially if a user configures a non-100% scaling parameter of Xft.dpi in the .Xdefaults configuration file. Here's a screenshot of my current build of FLWM with the Xft.dpi set to 128.0 (which is 133% bigger than default). If you don't want to take advantage of the fractional scaling for the window frames, you can leave Xft.dpi set at 96.0. Whether you scale the frame with Xft.dpi or not, you can still dynamically resize your window contents anytime you want with a hotkey or environment variable as documented earlier.
I've added some smartness to the window management buttons in the frame so that when the frame gets too small for the window title and all of the buttons to fit, one or more of the buttons can be hidden, and if the window gets really small, the title will be clipped.
Thanks to a good suggestion from the FLTK developer Google Group, I was able to resolve the issues with bad window resizing and lack of ability to grab the window frame on all sizes for resizing.
The attached picture is the classic left-side titlebars, but the "topside" version has the same updates.
Unfortunately, not all is well yet... I don't have the main pop-up menu (that you get by clicking on the desktop background) working properly. Will post again when I have that sorted (hopefully this weekend yet).
-
Hi MikeLockmoore
Looks good.
-
Hi MikeLockmoore
Looks good.
Thanks. I'm happy in how it's coming along. Maybe need to tweak a few pixels here and there yet.
In troubleshooting the FLWM main pop-up menu, I realized one of my main issues is that my .wmx/ folder is completely missing. :o :-[
Any suggestions on how to restore it easily? I checked the rootfs64.gz file but I don't see any of the /home/tc/* files on that.
-
Hi MikeLockmoore
You're missing the helper scripts for your window manager:
tc@E310:~$ grep SYSMENU /usr/local/bin/flwm_*
/usr/local/bin/flwm_topside_initmenu:SYSMENU=/home/"$USER"/.wmx
/usr/local/bin/flwm_topside_initmenu:[ -d "$SYSMENU" ] && rm -rf "$SYSMENU"
/usr/local/bin/flwm_topside_initmenu:mkdir -p "$SYSMENU"
/usr/local/bin/flwm_topside_initmenu:TARGET="$SYSMENU"/SystemTools && mkdir "$TARGET"
/usr/local/bin/flwm_topside_ondemand:SYSMENU=/home/"$USER"/.wmx
/usr/local/bin/flwm_topside_ondemand:[ -d "$SYSMENU" ] || mkdir -p "$SYSMENU"
/usr/local/bin/flwm_topside_ondemand:[ -d "$SYSMENU"/OnDemand ] && rm -rf "$SYSMENU"/OnDemand
/usr/local/bin/flwm_topside_ondemand: mkdir "$SYSMENU"/OnDemand
/usr/local/bin/flwm_topside_ondemand: cp "$F" "$SYSMENU"/OnDemand
In your case, they are called:
flwm_initmenu
flwm_makemenu
flwm_menu_common
flwm_ondemand
flwm_restart
flwm_rmitemYou can find them in flwm.tcz
-
Hi MikeLockmoore
You're missing the helper scripts for your window manager:
tc@E310:~$ grep SYSMENU /usr/local/bin/flwm_*
/usr/local/bin/flwm_topside_initmenu:SYSMENU=/home/"$USER"/.wmx
/usr/local/bin/flwm_topside_initmenu:[ -d "$SYSMENU" ] && rm -rf "$SYSMENU"
/usr/local/bin/flwm_topside_initmenu:mkdir -p "$SYSMENU"
/usr/local/bin/flwm_topside_initmenu:TARGET="$SYSMENU"/SystemTools && mkdir "$TARGET"
/usr/local/bin/flwm_topside_ondemand:SYSMENU=/home/"$USER"/.wmx
/usr/local/bin/flwm_topside_ondemand:[ -d "$SYSMENU" ] || mkdir -p "$SYSMENU"
/usr/local/bin/flwm_topside_ondemand:[ -d "$SYSMENU"/OnDemand ] && rm -rf "$SYSMENU"/OnDemand
/usr/local/bin/flwm_topside_ondemand: mkdir "$SYSMENU"/OnDemand
/usr/local/bin/flwm_topside_ondemand: cp "$F" "$SYSMENU"/OnDemand
In your case, they are called:
flwm_initmenu
flwm_makemenu
flwm_menu_common
flwm_ondemand
flwm_restart
flwm_rmitemYou can find them in flwm.tcz
Once again, again, you've provided the answer. Thanks!. I was able to run a few of these and got two of the submenus (OnDemand, and SystemTools) populated. Wasn't there a third menu with other local TCEs? In any case, I mostly have the topside version working with the windowblind "rollup" minimization button effect. Plus you can see the main popup menu in this screenshot (tricky to get without closing the menu!)
-
Here's a screenshot of the "minimize" (windowblind rollup) effect that is basically failing on Firefox and Geany. I'll probably post this to the FLTK Google Group and see if anyone has some ideas on how to manage this better.
-
Hi MikeLockmoore
... Wasn't there a third menu with other local TCEs? ...
Yes, it's called Applications. Things that you load onboot wind
up there.
-
Hi MikeLockmoore
... I was able to run a few of these and got two of the submenus (OnDemand, and SystemTools) populated. ...
Typically, menu items and wbar icons are handled through .desktop
files found in /usr/local/share/applications/. .desktop files with the
prefix tinycore- (i.e. tinycore-editor.desktop) wind up under the
SystemTools submenu. .desktop files are included in extensions
and handled by tce-load.
Here is a .desktop file:
tc@E310:~/fltktest/fltk_projects$ cat /usr/local/share/applications/grabber.desktop
[Desktop Entry]
Comment=Select a section of the screen with your mouse and save as .png file
Name=Selective Screenshot
Exec=/usr/local/bin/grabber
Icon=grabber
Terminal=false
X-FullPathIcon=/usr/local/share/pixmaps/grabber.png
Type=Application
Categories=Utility;
At the very least, a .desktop file should probably include:
Comment= A brief hint as to what the program does.
Name= The name displayed in the menu and when you hover over its icon.
Exec= Command to launch the program.
X-FullPathIcon= Location to fetch the icon image from (assuming you want an icon).
I think some of the other entries might be used by some fancier window managers.
-
Hi MikeLockmoore
... Wasn't there a third menu with other local TCEs? ...
Yes, it's called Applications. Things that you load onboot wind
up there.
Thanks. I've been looking into it, but the /usr/local/bin/flwm_makemenu script is not building the Applications subfolder under .wmx/ for me. No error messages if I run it directly from the command line. Just nothing happens. I think there is something weird in my setup that is starting FLWM ok after boot, but whatever is supposed to build the .wmx/ on each boot is not happening. Is there a tc-config script somewhere that is supposed to coordnate and ensure this stuff happens at boot before startx? Or startx is supposed to trigger?
One caveat about my TC 16 RC1 environment... I've changed the /etc/sysconfig/desktop file to refer to 'flwm_mike' instead of 'flwm' or 'flwm_topside', so that I run my most recent binary when run startx. (I have my IDE run the normal flwm "compileit" script, then copy either flwm or flwm_topside binary to /usr/local/bin/flwm_mike, and that binary is added to my .filetool.lst) Not sure if that causes some normal boot setup stuff from happening, but would be interested in sorting out this stuff. I know it was working at one point when I first set up the TC 16 RC boot config, but I've messed things up somehow. :-\
-
Hi MikeLockmoore
That's used in a bunch of places:
tc@E310:~/fltktest/fltk_projects$ grep desktop /usr/bin/tce*
/usr/bin/tce-load: [ -s /etc/sysconfig/desktop ] && desktop.sh "$APPNAME"
/usr/bin/tce-load: [ -s /etc/sysconfig/desktop ] && desktop.sh "$APPNAME"
/usr/bin/tce-run:if [ -f /usr/local/share/applications/${APP}.desktop ]; then
/usr/bin/tce-run: RUN=`cat /usr/local/share/applications/${APP}.desktop | grep Exec | cut -f2 -d=`
tc@E310:~/fltktest/fltk_projects$ grep desktop /usr/local/bin/desktop.sh
DESKTOP=`cat /etc/sysconfig/desktop`
tc@E310:~/fltktest/fltk_projects$ grep desktop /usr/local/bin/flwm_topside_*
/usr/local/bin/flwm_topside_makemenu:# Typically called from /usr/bin/desktop.sh
/usr/local/bin/flwm_topside_makemenu:# Check for freedesktop item
/usr/local/bin/flwm_topside_makemenu:if [ -s "$FREEDESK"/"$1".desktop ]; then
/usr/local/bin/flwm_topside_makemenu: if [ -s "$FREEDESK"/"$1"~1.desktop ]; then
/usr/local/bin/flwm_topside_makemenu: for F in $(ls "$FREEDESK"/* | grep -E "$1"'(~[1-9][1-9]*)*'.desktop); do
/usr/local/bin/flwm_topside_makemenu: writeFLWMitem "${FREEDESK}/${1}.desktop"
Just to name a few, there may be others.
You would need to change your window managers name and
its scripts to match the naming convention.
-
Thanks Rich. My prior method of overriding the FLWM binary, dropping out of the WM, and running startx (with a unique WM name in /etc/sysconfig/desktop) was not playing nice with the default desktop init stuff, so I changed things up to boot FLWM (from the .tcz) normally, then after I drop out of the WM, instead of just running startx, I have a wrapper script that can make a backup copy of the FLWM binary in /usr/local/bin, then replace the binary with my experimental FLWM build, then issue startx. Now I have all three sub-menus on my FLWM popup menu.
I'm also happy to report I've solved the weird "windowshade" rollup window minimize feature for the non-FLTK windows. Not sure it was really because some windows are not FLTK-native, but in any case, I have every type of window minimizing and coming back to normal as expected. Screenshot of the topside version with a few minimized windows (just showing horizontal titlebar strips).
-
Hi MikeLockmoore
... I'm also happy to report I've solved the weird "windowshade" rollup ...
Will the option to have minimized windows hidden still exist?
-
Hi MikeLockmoore
... I'm also happy to report I've solved the weird "windowshade" rollup ...
Will the option to have minimized windows hidden still exist?
Rich: Yes, the "iconify" button (upper left corner of the current "topside" build windows or lower left corner of the FLWM classic windows) will make the window disappear, but can be brought back by the desktop pop-up menu.
I've mulling over making an update to Flit, which is my system tray software, to be able to visualize the iconified apps and offer another way to pop them back to normal. But I have a lot of other pent-up updates to make, including finishing up any loose ends with FLWM and getting it ready for review, redoing the battery-monitor part of Flit, and some changes to make Fluff work better with the fractional scaling in FLWM, and much more... :P
-
Minor update... I realized I had an FLWM window title repaint issue, at least for the Fluff file manager, that if the window title changed such that the title text was shorter than before, some of the old text was not getting erased. I updated the FLWM title text clear call to cover most of the titlebar area. Hopefully most machines running TC 16 and beyond will have enough speed to not bog down repainting more pixels than absolutely necessary. :-[
-
Hi MikeLockmoore
If you still have access to the window title, why not erase it by
printing it again using the background color?
-
Hi MikeLockmoore
If you still have access to the window title, why not erase it by
printing it again using the background color?
There was already some code in FLWM to force a repaint in a "damaged" section of the window title bar, but it was based on the size of the text label widget. I just needed to make the rectangle bigger to make sure it covers the area the text could have been in before the label change size. Drawing the text in a different (background) color then painting the new text normally is an extra step. Not sure if it is actually slower, but it could be.
Update: Attached the set of FLWM code changes I'm testing. This is not super clean at this stage; it still has some commented-out debugging statements and other cruft I should remove. If you wish to apply it to the source code and try it, you may want to do something like (in the FLWM code folder):
$ git checkout master
$ git checkout -b mike_rescaling master
$ git checkout mike_rescaling
$ git apply mike_rescaling.patch
$ ./compileit
$ sudo cp flwm /usr/local/bin
(exit X to command prompt)
$ startx
--
Mike
-
On x86 (fltk-1.3) apart from this:
git apply mike_rescaling.patch
error: can't open patch 'mike_rescaling.patch': No such file or directory..things appear to work fine, except with flwm classic not all of the "X" in the exit button is rendered, perhaps the title bar is slightly too narrow?
On x86_64 (fltk-1.4) we are missing the two patches:
fltk-1.4-rotated-text.diff
flwm_border_redraw_bis.patch
(I'll add them), otherwise things look OK.
-
Hmm. I wasn't attempting to make something work for FLTK 1.3. Some of the calls in my mods are FLTK 1.4.x specific.
I have a patch set for cleaning up some commented-out debugging statements, and a few text edits in comments. i don't think there are any actual code changes in this patch set.
If you want me to look into the but graphic ("X" shape), I could try. Was that at Xft.dpi set at 96.0 and no non-1.0 scaling set in an environment variable? This patch is incremental to the one I posted yesterday.
-
The patch I tried to attach to my last reply didn't. :-\
However, I've managed to better center the X on the window close button, and added some line weight to make the symbols on the buttons a bit easier to see and scale OK if you bumps up the scaling factor. So this patch includes both the code comment cleanups mentioned before as well as the better button symbols code update. Only tested on TC 16 x86_64 (64 bit).
Note that this patch is incremental, mike_rescaling.patch should be applied first, then mike_rescaling_2.patch.
-
"git diff oldver..newver" will produce a combined patch.
-
The first chunk of mike_rescaling.patch duplicates a commit I made yesterday - if I remove that (and several trailing white space errors) I get:
git apply ../mike_rescaling.patch
error: patch failed: Frame.C:1110
..which doesn't seem to make sense?
-
The first chunk of mike_rescaling.patch duplicates a commit I made yesterday - if I remove that (and several trailing white space errors) I get: git apply ../mike_rescaling.patch
error: patch failed: Frame.C:1110
..which doesn't seem to make sense?
Not sure about that, and I don't see anything crazy in the patch file around that line number that should lead to trouble (not sure exactly what is at that line number in the pre-patched file. Is there a verbosity command line option with git apply *.patch to see more info about this?
If you still have trouble, maybe I can create a new single comprehensive patch to get to my code from the base version you would have straight from cloning the repo. I need to get to my day job now, so I'll come back at this in 12 hours, give or take. ;)
-
OK, got it - the last two patches I used to build flwm are included in your changes, which creates the error as they are already in master.
-
OK, got it - the last two patches I used to build flwm are included in your changes, which creates the error as they are already in master.
Great! :) I started with your build instructions which included at least one patch, and used that as the base of the patches I posted.
I'm not clear on the 32-bit x86 build issues. Does FLTK 1.4.x not support 32-builds now?
-
One of the main reasons to use fltk-1.4 is the wayland support, which means the tinycore fltk applets will work with a wayland compositor like labwc, weston, etc.
In order to reduce bloat, tinycore x86 does not use wayland. In addition fltk-1.4 is larger than fltk-1.3, so we decided to stay with fltk-1.3 for tc-16.x x86.
-
Using git apply -R ../xxx.patch, I was able to back out the couple of patches I'd added and then apply mike_rescaling.patch and mike_rescaling_2.patch cleanly.
I've posted updated flwm/flwm_topside to the tc-16.x x86_64 repo.
Building flwm for tc-16.x x86 (fltk-1.3) fails with: main.C: In function 'int main(int, char**)':
main.C:436:12: error: 'screen_scale' is not a member of 'Fl'
436 | sf = Fl::screen_scale(0);..which I guess is due to scaling not being supported on fltk-1.3
-
Hi Juanito
scale_factor was added in fltk-1.4.
-
I can try and rebuild Dillo for x86_64 with fltk-1.4 if that's of interest, but I'd normally wait until a stable release of TC 16 in order to upgrade the system I build it on. I won't do testing in Wayland.
watcher.tcz is another TC resource monitor that depends on FLTK 1.3. There's also alsamixergui.tcz.
-
FYI - libsane-dev.tcz is missing from the TCL16 x86_64 repo, making it difficult to compile some extensions. I took a quick look at the TCL16 x86 repo and it seems to be missing there, too.
I used the extension from TCL15 x86_64 on my TCL16 x86_64 machine and it seems to work fine.
-
Hi GNUser
Libsane was rebuilt for TC16. The .info file has an interesting comment:
Title: libsane.tcz
Description: lib files for sane
Version: 1.3.1
Author: see sane-doc AUTHORS
Original-site: https://gitlab.com/sane-project/backends
Copying-policy: GPL v 2
Size: 4.6M
Extension_by: aus9 @linuxquestions.org
Tags: scan scanner
Comments: There is no libsane-dev after update
replaced by sane-dev
Change-log: 2013/12/09 v 1.0.24 (Juanito)
Current: 2025/02/23 v 1.3.1 on 16x (aus9)Found here:
http://tinycorelinux.net/16.x/x86_64/tcz/libsane.tcz.info
And sane-dev.tcz.info has a related comment:
Title: sane-dev.tcz
Description: dev files
Version: 1.3.1
Author: see sane-doc AUTHORS
Original-site: https://gitlab.com/sane-project/backends
Copying-policy: GPL v 2
Size: 12K
Extension_by: aus9 @linuxquestions.org
Tags: scan scanner
Comments: Development replaces libsane-dev
Change-log: 2025/02/23 v 1.3.1 on 16x
Current: 2025/02/23Found here:
http://tinycorelinux.net/16.x/x86_64/tcz/sane-dev.tcz.info
-
Hi Rich. gtk3-dev.tcz fails to load for me because libsane-dev.tcz cannot not be found (libsane-dev still exists in gtk3-dev's dependency tree--see colord-dev.tcz.dep).
It seems libsane-dev needs to be changed to sane-dev in colord-dev.tcz.dep.
In TCL16 x86_64 at least, this seems to be the only dep file that needs to be fixed:
$ depends-on.sh libsane-dev
colord-dev.tcz
-
Hi GNUser
colord-dev.tcz.dep updated. :)
-
Hi Rich. Thank you :)
-
A couple of small tweaks to the tce-setup and tce-load scripts in the base initrd:
tce-setup diff:
63c63
< [ -f "$MOUNTPOINT"/"$TCE_DIR"/"$TARGETLIST"] || touch "$MOUNTPOINT"/"$TCE_DIR"/"$TARGETLIST"
---
> [ -f "$MOUNTPOINT"/"$TCE_DIR"/onboot.lst ] || touch "$MOUNTPOINT"/"$TCE_DIR"/onboot.lst
tce-load diff:
99c99
< [ "$THISAPP" != "$EXTENSION" ] || [ "$DOWNLOAD_ONLY" ] || [ "$LOAD_ONLY" ] || echo "$THISAPP" >> "$TCEDIR"/$ONBOOTNAME
---
> [ "$THISAPP" != "$EXTENSION" ] || [ "$DOWNLOAD_ONLY" ] || [ "$LOAD_ONLY" ] || echo "$THISAPP" >> ../$ONBOOTNAME
I think I got the diff order right - it'll make sense to whoever applies the patches.
These both should correct some file/dir reference issues when a couple of the bootcode-based overrides are used. These have needed tweaking for years. Sorry it took me so long to contribute.
Thanks,
idk
-
Maybe this is not the right place to discuss sound issues, but in the RC I have alsa and pulseaudio installed. I have the same issue others have posted where I need to unmute my speakers each time I reboot. I'd like my Flit sound applet be able to control sound without the PAVUcontrol needing to be installed, but as of now, PAVUcontrol is the only way to get sound working for me. I don't see yet anything PAVUcontrol does when unmuting that is different than the amixer and pactl commands I've tried to unmute the speakers form the command line. Any thoughts? Should I repost this issue in another thread?
-
Hi MikeLockmoore
... I don't see yet anything PAVUcontrol does when unmuting that is different than the amixer and pactl commands I've tried to unmute the speakers form the command line. Any thoughts? Should I repost this issue in another thread?
Yes, start a new thread in TCE Talk please.
-
TC16 doesn't boot on my 486DX4-100 laptop. After "Decompressing kernel... Parsing ELF...", then someting else which flashes up too quick to see, it reboots. I can try to frame-through a video of it if it would be useful to know the rest of the message. Perhaps there's a chance the kernel just won't start in the laptop's 16MB RAM anymore (rootfs.gz and modules.gz are unpacked to a HDD partition used as root= so they're not in RAM like a normal TC installation), but probably an illegal instruction.
Sorry I'm late with my usual 486 test. On my first attempt I reconnected the HDD wrong and killed it, losing my TC boot configuration in the process. I tested TC15 again though and (eventually) got it booting again. Replacing the TC15 vmlinuz file with the TC16 one causes the above behaviour. The same HDD transplanted into a 1GHz Intel Celeron laptop with 256MB RAM boots TC16 OK.
-
Hi CNK
... but probably an illegal instruction. ...
An illegal instruction usually causes the system to halt.
... Replacing the TC15 vmlinuz file with the TC16 one causes the above behaviour. ...
That kernel can't load any of the drivers from that HDD.
There was a recent thread about insufficient RAM with newer kernels:
https://forum.tinycorelinux.net/index.php/topic,27458.0.html
-
... but probably an illegal instruction. ...
An illegal instruction usually causes the system to halt.
I'm not sure in this case because it's before the kernel has properly started up (before the dmesg messages start). The behaviour might be different at that stage. It's probably before or at the beginning of the start_kernel stage as described here (https://ldp.ausics.net/HOWTO/Linux-Init-HOWTO.html).
... Replacing the TC15 vmlinuz file with the TC16 one causes the above behaviour. ...
That kernel can't load any of the drivers from that HDD.
Nah, it was booting to the TC16 rootfs.gz/modules.gz unpacked to a HDD, and the newer laptop runs off there fine. From earlier misadventures recreating my set-up after my HDD disaster I know that the kernel doesn't actually mount the root= partition (or fail to) until a good way later in the boot process than where the sudden reboot happens, so I just mentioned the vmlinuz file becuase loading things from the root filesystem isn't really relevant at that stage.
There was a recent thread about insufficient RAM with newer kernels:
https://forum.tinycorelinux.net/index.php/topic,27458.0.html
TC15 does boot in 16MB RAM with my HDD install configuration, it's not the same as running in the usual tmpfs. I'll see if I can catch the last boot message on video...
-
Hi CNK
You said that you unpacked rootfs.gz and modules.gz to the HDD.
The TC16 vmlinuz will accept the rootfs. But if needs any drivers
(kernel modules) for the 486, it won't load them because the
module version won't match the kernel version.
... TC15 does boot in 16MB RAM with my HDD install configuration, ...
Maybe TC16 needs more RAM.
-
Turns out the last messages that flash up are just normal before the kernel starts:
(https://objectstorage.ap-melbourne-1.oraclecloud.com/n/axqlf7atlxkh/b/attachments/o/tc16_pre-reboot.jpg)
Specifically they come from misc.c (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/boot/compressed/misc.c?h=v6.12) in the kernel sources. Converting the hex in kernel_total_size/needed_size it says it only needs 12.9MB for the kernel. Once it jumps to that main kernel code the PC reboots before any other messages are shown. Well before loading modules (which are correct for kernel 6.12.11-tinycore anyway, I just didn't mention switching them as well as vmlinuz the first time).
I might try on a Pentium 1 PC with more RAM to see if there's trouble booting there as well.
-
Hi CNK
Does your BIOS reserve any RAM, such as for video for example?
-
Does your BIOS reserve any RAM, such as for video for example?
When booted to a working Linux distro, dmesg shows 16384k available (16MB). It also says 408k "reserved" though I'm not sure if that's by the kernel or the hardware (I'd guess the kernel). More than 12.9MB left anyway. The laptop's manual says it has separate video memory (1MB).
I'd expect the kernel to handle running out of memory at that stage more gracefully anyway, since routines (such as in misc.c) allocate it in advance. The reboot still suggests an instruction set issue to me (the kernel itself can't print "illegal instruction" if the code to do that doesn't run).
-
The "apps" browser...
Have I mentioned how much I like the new layout? Having "Browse" hanging directly off of the "Apps" button instead of down one menu level doesn't sound like much of a change, but it's much easier to use.
-
TC16 does boot on my Pentium 1 PC with 80MB RAM. I'll see if I can install more RAM in the 486 laptop to see whether CPU or RAM is the problem there.
-
Hi CNK
See if this boot code eases memory pressure any:
udev.children-max=1
-
Thanks Rich, but yes I've got that already along with a bunch of other options I thought might reduce RAM (I've tried without these too). I think the problem happens before most of the options will take effect since they're typically associated with initialisation messages in dmesg and this happens before the dmesg output even starts.
Looks like udev.children−max=1 doesn't take effect until udevd (https://man.cx/udevd(8)) is started by /etc/init.d/tc-config, which is way later in the boot process.
I'll see what I can do towards upgrading RAM. The manual says 36MB max. but doesn't say how many RAM slots there are in the laptop or if they're standard 72pin SIMM type.
-
Ok, after a short hiatus, I'm back
History; TC16 Alpha release posts, https://forum.tinycorelinux.net/index.php/topic,27517.0.html
I've done many hours of testing to narrow down the problems I've had on running TC16 on various VIA Technologies C7 single core x86 32bit microprocessor based machines
Rich mentioned;
Just my opinion, but unless you have some compelling reason to
move to TC16, you might want to consider sticking with TC15 if
it works on your system.
Which is a valid suggestion, but it doesn't quite fit my situation because;
1: TCL is one of the few 32bit distros remaining, and these are all x86 based machines, so I don't have many choices left. I don't know why or when x86 became a dirty word.
2: I am the sole beta tester for the VIA graphics Openchrome project, and I work with the sole developer of Openchrome Linux video drivers, so...
3: I have a vested interest in being able to put these machines to good use, and...
4: It would be a shame to not have a whole series of machines be able to take advantage of the work and updates TC16 provides.
That being said, I have narrowed down my problems.
1: The TC16 Kernel used always locks up, only the printk modified Kernel; vmlinuz-6.12.11-printkdelay from http://tinycorelinux.net/16.x/x86/debug/ works properly
2: I have had no problems using the printk Kernel, except as follows:
3: Using the printk Kernel, coreutils.tcz causes the eventual lockup of the machine, running a loop using echo and sleep from coreutils.tcz, I haven't tested other utilities from that package.
I don't know how y'all want to proceed, possibly replace the TC16 Kernel with the printkdelay version, at minimum I would hope that the printk Kernel remains available for people with affected machines, along with release notes to let them know.
As far as coreutils goes, there is a newer version available.
I don't know what the root cause of the lockups are, perhaps toolchain or cross compiler options. I am not sure what the difference between the compilation of Rich's printkdelay Kernel, and the original TC16 Kernel.
I know the forum rules forbid the asking of hardware, but doesn't say anything about the offering of hardware. Due to my vested interests, I have made a few bulk purchases of these machines for development and testing purposes. I would be willing to donate a machine or 2 if it would help, as they are doorstops without working software. I am located in Chicago, IL so I'm not above bribing y'all. Please contact me off-list and I'll see what I can do.
Eric.
-
FWIW I've got a HP 2533t with a VIA C7-M. I can try booting TC16 on it if that's any use. The service manual lists the full processor spec as: "Via C7-M Ultra-Low Voltage (ULV) 1.00-GHz, 128-KB L2 cache, 400-MHz front side bus (FSB)"
-
Hi CNK
TC16 does boot on my Pentium 1 PC with 80MB RAM. I'll see if I can install more RAM in the 486 laptop to see whether CPU or RAM is the problem there.
Unpack core.gz to the hard drive like you did for the 486.
Then try booting with this boot code included:
mem=16M
-
TC16 does boot on my Pentium 1 PC with 80MB RAM. I'll see if I can install more RAM in the 486 laptop to see whether CPU or RAM is the problem there.
Unpack core.gz to the hard drive like you did for the 486.
Then try booting with this boot code included:
mem=16M
I gave that a try on the Intel Celeron laptop. TC16 fails then too, but with loads of error messages not shown on the 486. On TC15 it boots further, but doesn't get through tc-config (killed due to low RAM) and then doesn't activate the swap partition (I moved that step right after udev start in my custom tc-config), which does work on the 486 with real 16MB RAM.
So yeah it might just be a RAM issue, but nothing quite matches up with mem=16 on newer hardware Vs physical 16MB on the 486. RAM use might depend on what kernel built-in drivers are used. I use the Pentium 1 PC every day (writing this on it), so I prefer to test these things on other computers that don't have to be reassembled immediately.
Of three 486 laptops I have, the only one taking standard RAM sticks has too low-spec of a 486. I'll see if I can set up a 486 desktop PC with more RAM, or upgrade that 486 laptop if it's possible.
-
FWIW I've got a HP 2533t with a VIA C7-M. I can try booting TC16 on it if that's any use. The service manual lists the full processor spec as: "Via C7-M Ultra-Low Voltage (ULV) 1.00-GHz, 128-KB L2 cache, 400-MHz front side bus (FSB)"
i am interested in the results of this test. thanks.
-
I tested TC16 on a desktop PC with an AM486DX2-66 and 20MB of RAM. The system reboots at the same point when the kernel should start. TC15 boots fine (in under 40 seconds with my stripped-down tc-config) and doesn't even use the swap space.
I'll see if I can find some bigger RAM sticks to increase the RAM more significantly above 16MB (might take a while, RAM was even more poorly labeled in those days) in case the TC16 kernel needs way more for some reason. But I'm more convinced that it's a processor compatibility problem with the new kernel.
Will test on the HP 2533t too once I sort out how to get TC16 onto it. Some of the features I've tried disabling on the kernel command line for the 486 might be worth trying with that as well:
highres=off mitigations=off nosmp nosmt acpi=off
-
To anyone following this thread, posts relating to updating
fluff, flit, and flpicsee have been split off to their own thread:
https://forum.tinycorelinux.net/index.php/topic,27574.0.html
-
To anyone following this thread, posts relating to updating
fluff, flit, and flpicsee have been spit off to their own thread:
https://forum.tinycorelinux.net/index.php/topic,27574.0.html (https://forum.tinycorelinux.net/index.php/topic,27574.0.html)
Thanks, Rich. That makes sense.
FWIW, I've been doing all my fluff testing on Core 16.0beta1 / x86_64 and the RC seems rock solid on my laptop. I haven't been back to 15.0 since 16.0apha1 was posted except for once when I wanted to verify something. (mind you, I have backups, just in case.)
-
Will test on the HP 2533t too once I sort out how to get TC16 onto it. Some of the features I've tried disabling on the kernel command line for the 486 might be worth trying with that as well:
highres=off mitigations=off nosmp nosmt acpi=off
Regardless of those options the boot process hangs on my HP 2533t with the standard TC16 kernel. It always hangs either immediately after the "run /sbin/init" message, or at some random point during tc-config. The vmlinuz-6.12.11-printkdelay kernel boots fine. Tried booting from USB and from its PATA flash drive with all peripherals disabled in the BIOS, but same issue with the standard TC16 kernel.
It's curious that the standard kernel never hangs before the init process is started. I wonder if it's something to do with the task scheduler? I'll try some scheduler-related kernel boot commands when I get the time/energy.
Dmesg shows a message suggesting that "tsc=unstable" be added to the kernel command line (in TC15 and TC16), but adding that doesn't help the TC16 kernel boot. Maybe use "clocksource=hpet" instead of default "clocksource=tsc"? No time to dig deeper, I should be working now...