Recent Posts

61

TCE Talk / Re: New package manager

« Last post by wysiwyg on February 01, 2026, 06:44:50 PM »

It seams that TC developers think that users initially search for apps, then users settle with some apps and updates seldom.

That's pretty much what I do.  I have recently started doing occasional extension updates but I haven't exactly made a habit of it.

In a future version pax will have the ability to alert and/or automatically perform this task.  I just needed to iron out what needed to be done beforehand.  Most people don't do updates if they don't know they are available.  Actually most people don't install updates even when they're told they have them.  This is obviously unsafe and leaves you subject to exploits...

62

TCE Talk / Re: New package manager

« Last post by wysiwyg on February 01, 2026, 06:42:53 PM »

Hey Nick!  Thanks for adding to the discussion!

I followed this discussion with interest, tce* scripts are good, no perfect! For me, all is just an intellectual challenge, but not a BIG win in any direction-solution developers will chose to pursuit.
For "modern" hardware (multi-core CPU, SDD or Nvram storage, fast 100MB..1GB network links, etc) is .. not worthy. So the "new" pax package could have a meaningful gain only for outdated surviving hardware like 486 CPU, with small HDD storage, small 128MB RAM, 10MB NIC card etc.

I agree that the TC developers are most likely going to leave the tce-* scripts as is, which is fine. They are a barebones way to accomplish their task.  But to say that pax is only meaningful for older hardware, would be incorrect.  pax has a much larger feature set than the default tce-* scripts, including one that has been requested for many years - the ability to unload software.  I would invite you to read the .info file associated with the project to see the abilities it has over the default manager(s).

http://tinycorelinux.net/16.x/x86/tcz/pax.tcz.info

Which is actually the original version.  I sent the latest version at the end of last week that hasn't been processed yet.  There isn't much change by way of code, but it does provide an in-depth man page to further explain some of the features.  Of course, feedback is always welcome to make it better if something is unclear.

Because, as Rich said 0.2 .. 2 seconds is enough to load all "non-software" repo metadata. Looking into https://mirrors.dotsrc.org/tinycorelinux/17.x/x86_64/tcz/ I see provides.db.gz =3.1 MB, but provides.db.zsync = 175KB!!

1. Using TC on USB, users will not premature destroy their pen/stick with too many updates.
2. Using TC on HDD, will have permanent /tce/optional folder (aka static on HDD, sometime even cache in RAM for a session), and seldom using zsync for 175KB extra. 

From my past experience, many TCZ extension are not often updated, because new versions have bigger size. But tiny is about just core (not very useful by itself without apps), not the full system as used by most users. It seams that TC developers think that users initially search for apps, then users settle with some apps and updates seldom.

My original gripe was more so about being efficient with things.  I did also think that the way TC was handling it was an exception, not the rule.  And yes, 3.1MB is not very much in size.  But when 10 people use it, that becomes 31MB, when 100 people use it is becomes 310MB, when 1000 people use it is becomes 3.1GB, etc.  And remember that this is donated bandwidth.  I'll still add in the ability to search using an online URL, but I'll also have to expand that to include entire repo db's to work across various distros.

In summary the idea to use a new package management revolves in replacing wget (from busybox)  with SQLite, or maybe CURL+dependencies, by increasing the TINY base/core.

I'm not sure what advantage that would give you.  You would still have to download the entire database to your local device, defeating the efficiency I was aiming for.  And the reason wget was chosen is because with basic package management, you only need to download packages, which wget works very well at - plus its part of busybox so no additional dependencies.  cURL adds another dependency to the mix, adding extra size to the base - of which TC tries to keep as small as possible.  I will attempt to use wget to handle the searching side, but I may have to revert to cURL.  But my design goals are different than TC.  I do want small and efficient, but not at the expense of traditional features.

63

TCE Talk / Re: New package manager

« Last post by Leee on February 01, 2026, 06:15:02 PM »

It seams that TC developers think that users initially search for apps, then users settle with some apps and updates seldom.

That's pretty much what I do.  I have recently started doing occasional extension updates but I haven't exactly made a habit of it.

64

TCE Talk / Re: New package manager

« Last post by nick65go on February 01, 2026, 05:14:19 PM »

I followed this discussion with interest, tce* scripts are good, no perfect! For me, all is just an intellectual challenge, but not a BIG win in any direction-solution developers will chose to pursuit.
For "modern" hardware (multi-core CPU, SDD or Nvram storage, fast 100MB..1GB network links, etc) is .. not worthy. So the "new" pax package could have a meaningful gain only for outdated surviving hardware like 486 CPU, with small HDD storage, small 128MB RAM, 10MB NIC card etc.
Because, as Rich said 0.2 .. 2 seconds is enough to load all "non-software" repo metadata. Looking into https://mirrors.dotsrc.org/tinycorelinux/17.x/x86_64/tcz/ I see provides.db.gz =3.1 MB, but provides.db.zsync = 175KB!!

1. Using TC on USB, users will not premature destroy their pen/stick with too many updates.
2. Using TC on HDD, will have permanent /tce/optional folder (aka static on HDD, sometime even cache in RAM for a session), and seldom using zsync for 175KB extra. 

From my past experience, many TCZ extension are not often updated, because new versions have bigger size. But tiny is about just core (not very useful by itself without apps), not the full system as used by most users. It seams that TC developers think that users initially search for apps, then users settle with some apps and updates seldom.

In summary the idea to use a new package management revolves in replacing wget (from busybox)  with SQLite, or maybe CURL+dependencies, by increasing the TINY base/core.

65

TCE Talk / Re: pcmanfm for TC17 x86_64

« Last post by Rich on February 01, 2026, 11:43:18 AM »

Hi aus9
A few things are catching my eye.

...

Code: [Select]

pcmanfm
pcmanfm: error while loading shared libraries: libfm-gtk3.so.4: cannot open shared object file: No such file or directory
 ----- Snip ----- ...

When libfm.tcz gets loaded, ldconfig gets run automatically and that library should be found.

Also, what's going on with this tce.installed/ file?

Code: [Select]

rich@tcbox:~$ cat pkg/usr/local/tce.installed/libfm
#!/bin/sh
# avoid libfm-extra-dev duplication
P=libfm
LOOP1=/tmp/tcloop/$P/usr/local/lib
rm -rf /usr/local/lib/$P*so*
# The linking is what TC would have done if it was simple
ln -s $LOOP1/$P*so*  /usr/local/lib

 ----- Snip -----
libfm-extra-dev needs to be split into  libfm-extra-dev.tcz  and  libfm-extra.tcz.

libfm-extra-dev currently contains:

Code: [Select]

/usr/local/lib/libfm-extra.so.4.1.3
/usr/local/lib/libfm-extra.so.4
/usr/local/lib/libfm-extra.so
/usr/local/lib/pkgconfig/libfm-extra.pc
/usr/local/include/libfm
/usr/local/include/libfm-1.0/fm-extra.h
/usr/local/include/libfm-1.0/fm-version.h
/usr/local/include/libfm-1.0/fm-xml-file.h
libfm-extra-dev should contain:

Code: [Select]

/usr/local/lib/pkgconfig/libfm-extra.pc
/usr/local/include/libfm
/usr/local/include/libfm-1.0/fm-extra.h
/usr/local/include/libfm-1.0/fm-version.h
/usr/local/include/libfm-1.0/fm-xml-file.h
libfm-extra should contain:

Code: [Select]

/usr/local/lib/libfm-extra.so.4.1.3
/usr/local/lib/libfm-extra.so.4
/usr/local/lib/libfm-extra.so
libfm-extra.tcz should be added to libfm-extra-dev.tcz.dep

The following should be removed from libfm.tcz:

Code: [Select]

/usr/local/lib/libfm-extra.so.4.1.3
/usr/local/lib/libfm-extra.so.4
/usr/local/lib/libfm-extra.so
libfm-extra.tcz should be added to libfm.tcz.dep

Continuing with tce.installed/libfm:

Code: [Select]

----- Snip -----

# make modules Dir that is read-write
rm -rf /usr/local/lib/$P/modules
mkdir -p /usr/local/lib/$P/modules
LOOP2=/tmp/tcloop/$P/usr/local/lib/$P/modules
cp $LOOP2/*.so /usr/local/lib/$P/modules
I think the directory should already be writable by root.

Why are you copying the .so files instead of linking them in.
That defeats the whole purpose of mount mode.

66

Release Candidate Testing / Re: Core v17.0beta1

« Last post by Rich on February 01, 2026, 10:36:26 AM »

Hi aus9

I did it the ldd the wrong way around.

Yeah, I figured that out.

I split off your pcmanfm topic to its own thread here:
https://forum.tinycorelinux.net/index.php/topic,27989.0.html

This thread is really about the release of base components (vmlinuz, core.gz, modules.gz, etc).

67

Release Candidate Testing / MOVED: pcmanfm for TC17 x86_64

« Last post by Rich on February 01, 2026, 10:31:39 AM »

This topic has been moved to TCE Talk.

https://forum.tinycorelinux.net/index.php?topic=27989.0

68

TCE Talk / pcmanfm for TC17 x86_64

« Last post by aus9 on February 01, 2026, 02:01:54 AM »

@Rich
Ok the next a small explanation. As you know I build seatd wrong so copy2fs users had trouble. Here on 17x I have built and am testing a copy2fs build of pcmanfm. It may or may be accepted but I just discovered that libtool needs sed (full  sed not busybox sed) to work correctly as per code box

Code: [Select]

pcmanfm
pcmanfm: error while loading shared libraries: libfm-gtk3.so.4: cannot open shared object file: No such file or directory
tc@box:~$ libtool --finish /usr/local/lib/
/usr/local/bin/libtool: line 971: /usr/local/bin/sed: not found
/usr/local/bin/libtool: line 1384: /usr/local/bin/sed: not found
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib/

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the '-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the 'LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the 'LD_RUN_PATH' environment variable
     during linking
   - use the '-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to '/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
tc@box:~$ pcmanfm
pcmanfm: error while loading shared libraries: libfm-gtk3.so.4: cannot open shared object file: No such file or directory
tc@box:~$ tce-load -i sed
sed.tcz: OK
tc@box:~$ libtool --finish /usr/local/lib/
libtool: finish: PATH="/home/tc/.local/bin:/home/tc/firefox:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin" ldconfig -n /usr/local/lib/
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib/

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the '-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the 'LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the 'LD_RUN_PATH' environment variable
     during linking
   - use the '-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to '/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
tc@box:~$ pcmanfm

** (pcmanfm:4780): WARNING **: 14:54:39.284: modules directory is not accessible

(pcmanfm:4780): Gtk-WARNING **: 14:54:39.323: Theme parsing error: <data>:2:27: The style property GtkWidget:focus-padding is deprecated and shouldn't be used anymore. It will be removed in a future version

(pcmanfm:4780): Gtk-WARNING **: 14:54:39.323: Theme parsing error: <data>:3:30: The style property GtkWidget:focus-line-width is deprecated and shouldn't be used anymore. It will be removed in a future version

(pcmanfm:4780): Gtk-WARNING **: 14:54:42.378: gtk_menu_detach(): menu is not attached
pcmanfm GUI is working as expected now

Code: [Select]

ls -al /bin/sed
lrwxrwxrwx    1 root     root             7 Jan 25 00:07 /bin/sed -> busybox
cat /usr/local/bin/libtool | grep "/bin/sed"
SED="/usr/local/bin/sed"
global_symbol_pipe="/usr/local/bin/sed -n -e 's/^.*[ ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[ ][ ]*\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2 \\2/p' | /usr/local/bin/sed '/ __gnu_lto/d'"
global_symbol_to_cdecl="/usr/local/bin/sed -n -e 's/^T .* \\(.*\\)\$/extern int \\1();/p' -e 's/^[ABCDGIRSTW][ABCDGIRSTW]* .* \\(.*\\)\$/extern char \\1;/p'"
global_symbol_to_c_name_address="/usr/local/bin/sed -n -e 's/^: \\(.*\\) .*\$/  {\"\\1\", (void *) 0},/p' -e 's/^[ABCDGIRSTW][ABCDGIRSTW]* .* \\(.*\\)\$/  {\"\\1\", (void *) \\&\\1},/p'"
global_symbol_to_c_name_address_lib_prefix="/usr/local/bin/sed -n -e 's/^: \\(.*\\) .*\$/  {\"\\1\", (void *) 0},/p' -e 's/^[ABCDGIRSTW][ABCDGIRSTW]* .* \\(lib.*\\)\$/  {\"\\1\", (void *) \\&\\1},/p' -e 's/^[ABCDGIRSTW][ABCDGIRSTW]* .* \\(.*\\)\$/  {\"lib\\1\", (void *) \\&\\1},/p'" 
Originally I just grepped sed but too many lines

69

Release Candidate Testing / Re: Core v17.0beta1

« Last post by aus9 on February 01, 2026, 01:36:10 AM »

Rich
I did it the ldd the wrong way around. Silly me

70

Release Candidate Testing / Re: Core v17.0beta1

« Last post by Rich on January 31, 2026, 11:01:24 PM »

Hi aus9
I mounted both http://tinycorelinux.net/16.x/x86_64/tcz/libSM.tcz and
http://tinycorelinux.net/16.x/x86/tcz/libSM.tcz and ran readelf on them.
Both returned the following:

Code: [Select]

rich@tcbox:~$ readelf -d pkg/usr/local/lib/libSM.so | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libICE.so.6]
 0x00000001 (NEEDED)                     Shared library: [libuuid.so.1]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
I'll add .dep files for both versions.