Recent Posts

31

TCE Q&A Forum / Re: TCL 64: Libreoffice Draw and Impress not working

« Last post by CNK on December 01, 2024, 05:19:41 PM »

Firefox_getLatest.sh creates this symlink:

Code: [Select]

ln -s /lib /lib64

That might be what your Appimage needs. Extension dependencies vary between AppImages. In theory any of these libraries might be needed.

32

TCE Talk / Re: Dependent TCZs Scanner for TCZ Maintainers

« Last post by Paul_123 on December 01, 2024, 01:13:11 PM »

just left overs from the beta releases.  Raspi typically has major hardware releases while in the middle of a kernel release cycle, so I often upgrade the piCore kernels between beta and release and sometimes on dot releases.

33

Off-Topic - The Funnies / Why, in my day... and we LIKED it! / Four Yorkshiremen

« Last post by mocore on December 01, 2024, 01:09:32 PM »

[1] https://tinyapps.org/blog/200702250700_why_in_my_day.html

ftr via https://msfn.org/board/topic/173117-rebootpro-status/page/2/
 found this after  looking any mention of boot issues similar those mentioned in ' Re: Black screen TinyCorePure64-15.0 and Ventoy' 

... unfortunately the site was down , but this(&linked/quoted) post made me lol

Well, I would say that there is a not-so-fine line between the management of a hobby internet forum and a production floor.

I obviously belong to another (past :ph34r:) era but in my day[1] production ruled over anything else, and managers (at the time there actually existed "real" managers) would have kicked asses left and right (and top and bottom) if someone caused a three hours stop, let alone if it was a recurring issue.

Though of course the IT department always was an exception, btw one of the reasons why I am somehow familiar with PC's is because historically the IT guys have been " a bunch of mindless jerks (who'll be the first against the wall when the revolution comes)".

jaclaz

...
 

Why, in my day... and we LIKED it! #

One of my favorite memes on Slashdot is the "Why, in my day..." (along the lines of Monty Python's Four Yorkshiremen). Here is a taste:

    Old guy #1: Yes, sir, a six-bit character set was all we had, and we liked it!

    Old guy #2: You had a character-set? Damn you were lucky! Back in MY day all we had was a bunch of rocks, and we communicated by banging the rocks together.

    Old guy #3: Rocks!! Do you know what we would have done for rocks! A good honest rock could get you places. No Sir. All we had was mud. Mud and straw. We used to pile the mud up into segments to make registers and then use the straw to represent numbers. We didn't have any of your holier than thou binary formats. No Sir. We had unary and we liked it.

    Old guy #1: In my day, we made our CPUs out of crystals! Our motherboard was a clay tablet. And we hammered the gold into thin sheets, baked it in a dung-fired oven, and we LIKED it.

    Old guy #2: Luxury. Back when I was a young'en, we didn't have any o' those fancy crystals, ovens or precious metals. We 'ad to make due with a bunch o' stones, manipulating the electrons by hand!

    Old guy #1: The TRUE geek makes his own from a brick of silver. In my day we had to make thermal paste by grinding it down with stones.

    Old guy #2: Silver bricks? You was lucky! In my day we had mine our own ore and smelt it down. Then our dad would assay it, and if it wasn't 99% pure, all we got for breakfast was CompUSA Silver Thermal Grease!

    Old guy #3: You had HEAVY ELEMENTS? In my day, the loose clouds of interstellar gas hadn't coalesced into star systems yet. All we had were hydrogen atoms and maybe a trace of helium around Christmas!

    Old guy #4: You had loose clouds of interstellar gas. *LUXURY* In my day we had nothing but the vacuum and had to wait for a universe to pop into existence before we could even begin to think about the existence of energy and matter. Kids today ....

wishing all at least a trace of helium !

... amongst the methane 

34

TCE Talk / Re: Dependent TCZs Scanner for TCZ Maintainers

« Last post by Rich on December 01, 2024, 12:31:38 PM »

Hi Sashank999

... I did not understand this comment. What is the problem with ExtensionName-KERNEL.tcz ? ...

My script was designed to let you ask "will my TC10 version of ProgramXYZ run on TC13?"
In that case, you can't use  uname  to pick a  KERNEL  value.

Multiple kernels.
It hasn't happened often for Intel architectures, but it has happened.
TC3:

Code: [Select]

alsa-modules-2.6.33.3-l1-rt19.tcz
alsa-modules-2.6.33.3-tinycore.tczTC4:

Code: [Select]

alsa-modules-3.0.32-x1-rt52.tcz
alsa-modules-3.0.21-tinycore.tcz
alsa-modules-3.0.3-tinycore.tczAnd all of the x86 repos also contain 64 bit versions of KERNEL for
running Core64 (64 bit kernel and modules, 32 bit apps).

Now try it on piCore.
TC15 armv6 (armhf):

Code: [Select]

alsa-modules-6.6.28-piCore.tcz
alsa-modules-6.6.34-piCore.tcz
alsa-modules-6.6.47-piCore.tczOr for TC15 aarch64:

Code: [Select]

alsa-modules-6.6.28-piCore-v8.tcz
alsa-modules-6.6.34-piCore-v8.tcz
alsa-modules-6.6.47-piCore-v8.tcz
alsa-modules-6.6.28-piCore-v8-16k.tcz
alsa-modules-6.6.34-piCore-v8-16k.tcz
alsa-modules-6.6.47-piCore-v8-16k.tczI don't know if those first three are used or just leftovers.

By the way, a tree file can/will contain a version string, but which one?

35

TCE Talk / Re: Dependent TCZs Scanner for TCZ Maintainers

« Last post by polikuo on December 01, 2024, 12:22:52 PM »

I did not understand this comment. What is the problem with ExtensionName-KERNEL.tcz ?
The problem that you described, which I think is what you are saying for your script, only occurs when you are using the .dep files. The .tree files contain the KERNEL part of the TCZ name replaced with the KERNEL version so I don't think there will be a problem with my script. As my script does not include the option of running it for a different TCL version than the hardcoded values, I do not think it has such a problem.

One thing that I would like to admire is that both of you, and many others as well, created shell scripts to do this, and not Python. I really cannot do this in shell. You guys are good at this !

The problem is, all kernel module should follow that convention for dep files.
Kernel release may change value.
Thus in all dep files, we use string -KERNEL to denote that the extension is a kernel module.
Your script doesn't process those files, neither reading nor writing.

For example

Code: [Select]

$ uname -r
6.6.8-tinycoreThis is the kernel release, sometimes there maybe some major bugs in kernel.
If kernel 6.6.8 has one of those and 6.6.9 fixes that problem.
Then, after some evaluation, TC team will release TC15.1 with kernel 6.6.9

On the other hand, whenever a newer major release occurs, we move on to newer kernel.
Most packages can be copied directly without any trouble.
It would be tedious if we put actual kernel string into dep files.

36

TCE Talk / Re: Dependent TCZs Scanner for TCZ Maintainers

« Last post by Sashank999 on December 01, 2024, 11:23:37 AM »

Hello.

If you browse the forum more, you can see tons of scripts written by different individuals.
In case you're interested, you can check out mine here on the forum, or on my github.
They are old, my skill was immature back then, sometimes I do want to rewrite it, but I always got occupied.
Anyway, if you find anything useful in my script, feel free to implement them into yours.

I expected someone to be doing something like this, but there are really a lot of such scripts. I am also intrigued by your script's ideas, but I still don't know what I can add from your script. And we really thought of (almost) the same name for our scripts.
I would like to work on my script a bit more. I think we can think a bit more about the ways we can solve this problem.

In my version you just told it which binary to check and and for which TC version.
It would create a .dep file for that TC version and report any missing libraries.

Kernel modules are listed as  ExtensionName-KERNEL.tcz  and will
show up as  ExtensionName-KERNEL.tcz.dep  with a file size of zero.
Since there is the possibility of more than one kernel version for
modules in a release, and the check you are running may be for a
different TC version, automating this is likely not possible.

I did not understand this comment. What is the problem with ExtensionName-KERNEL.tcz ?
The problem that you described, which I think is what you are saying for your script, only occurs when you are using the .dep files. The .tree files contain the KERNEL part of the TCZ name replaced with the KERNEL version so I don't think there will be a problem with my script. As my script does not include the option of running it for a different TCL version than the hardcoded values, I do not think it has such a problem.

One thing that I would like to admire is that both of you, and many others as well, created shell scripts to do this, and not Python. I really cannot do this in shell. You guys are good at this !

37

TCE Talk / Re: Dependent TCZs Scanner for TCZ Maintainers

« Last post by Rich on December 01, 2024, 10:51:01 AM »

Hi Sashank999
I did something like that a couple of years ago:
https://forum.tinycorelinux.net/index.php/topic,26040.0.html
In my version you just told it which binary to check and and for which TC version.
It would create a .dep file for that TC version and report any missing libraries.

... uses ldd to find the libraries they depend on.

It checks the /etc/sysconfig/tcedir/provides.db for the TCZs that provide those libraries. These are listed in an "initial scan" log. ...

That's what I did.

... Then, this script checks if there are any unnecessary dependencies, like listing both child and parent dependent TCZs. It does this by downloading the .tree files for one dependent TCZ at a time (it also has a local cache for .tree files so that the same .tree file does not get downloaded twice). ...

I took a different approach:

Code: [Select]

search provides.db for library
if found
    echo FILE.TCZ >> $DependencyList
else
    # Check /lib and /usr/lib to see if it's part of the base system.
    [ -f "/lib/$LIB" ] && continue
    [ -f "/usr/lib/$LIB" ] && continue
    # LIB was not found.
    echo " ******************* Missing $LIB" >> "$MissingDeps"
fi

# This sorts the file in place and removes duplicates.
echo "$(sort -uf "$DependencyList")" > "$DependencyList"


mkdir "$NEEDEDDEPSDIR"
mkdir "$UNNEEDEDDEPSDIR"

# Create a directory of .dep files for further processing.
RUN=1

while [ $RUN -eq 1 ]
do
    RUN=0
    for F in `cat "$DependencyList"`
    do
        # Skip this entry if it already exists.
        [ -f "$NEEDEDDEPSDIR$F.dep" ] && continue
        wget -q -O "$NEEDEDDEPSDIR$F.dep" "$URL$F.dep" 2>&1 | grep -q "404 Not Found"
        if [ $? -eq 0 ]
        then    # We drop into here if grep succeeds in finding "404 Not Found".
            # Create a temporary dummy .dep file if one doesn't exist.
            touch "$NEEDEDDEPSDIR$F.dep"
        else
            cat "$NEEDEDDEPSDIR$F.dep" >> "$DepContents"
            # We continue running as long as more dependencies are found.
            RUN=1
        fi
    done

    echo "$(sort -uf "$DepContents")" > "$DepContents"
    cp "$DepContents" "$DependencyList"

done

# We now have a directory of .dep files and a list of their contents.
# If a file is on the list, its .dep file can be moved to $UNNEEDEDDEPSDIR.
for F in $(cat "$DepContents")
do
    # Skip this entry if it doesn't exist.
    [ ! -f "$NEEDEDDEPSDIR$F.dep" ] && continue
    mv "$NEEDEDDEPSDIR$F.dep" "$UNNEEDEDDEPSDIR"
done

# Create dependency file.
for F in $(ls -1 "$NEEDEDDEPSDIR" | sort -f)
do
    echo ${F%.dep} >> "$WORKDIR/Result.dep"
done
Kernel modules are listed as  ExtensionName-KERNEL.tcz  and will
show up as  ExtensionName-KERNEL.tcz.dep  with a file size of zero.
Since there is the possibility of more than one kernel version for
modules in a release, and the check you are running may be for a
different TC version, automating this is likely not possible.

38

TCE Talk / Re: Dependent TCZs Scanner for TCZ Maintainers

« Last post by polikuo on December 01, 2024, 10:42:25 AM »

Hi, Sashank999.

Dependency is not always that easy.
For small library, yes, such script will do.
If you browse the forum more, you can see tons of scripts written by different individuals.
In case you're interested, you can check out mine here on the forum, or on my github.
They are old, my skill was immature back then, sometimes I do want to rewrite it, but I always got occupied.
Anyway, if you find anything useful in my script, feel free to implement them into yours.

39

TCE Talk / Dependent TCZs Scanner for TCZ Maintainers

« Last post by Sashank999 on December 01, 2024, 08:36:24 AM »

Hello.

I was trying to create and submit a TCZ to the repo when I just found out that we have to find out the list of TCZs that will be used by an extension's binaries (i. e., dependent TCZs) manually.
I just wrote a small script in Python that checks the files in a directory, scans the files to check if they are ELF files (both executables and shared objects have the same magic bytes IIRC) and then uses ldd to find the libraries they depend on.

It checks the /etc/sysconfig/tcedir/provides.db for the TCZs that provide those libraries. These are listed in an "initial scan" log.

Then, this script checks if there are any unnecessary dependencies, like listing both child and parent dependent TCZs. It does this by downloading the .tree files for one dependent TCZ at a time (it also has a local cache for .tree files so that the same .tree file does not get downloaded twice).

All these will be stored in a .dep file, named as "first argument.dep", in the directory of the call of the script. Thus your first parameter to the script must be "newextension.tcz".

It also has a verbose mode so that the .tree files that are downloaded and the redundant dependencies removed during resolution are printed to stdout.

The script is written and tested with Python 3.9 in the TCL v15 x86_64 repo.

Please let me know if there are any improvements that I can do so that this script suits other's needs.
Note: The script is currently unlicensed. I plan on MIT licensing it if necessary.

Thank you.

40

Off-Topic - Tiny Core Lounge / the TTY demystified

« Last post by mocore on December 01, 2024, 07:11:56 AM »

Learn. Share. Grow your knowledge of Linux.

i was skimming through
  "the TTY demystified" @ https://www.linusakesson.net/programming/tty/index.php

ans wandered if it had been posted this hear ( search didn't find any previous mentions)

The TTY subsystem is central to the design of Linux, and UNIX in general. Unfortunately, its importance is often overlooked, and it is difficult to find good introductory articles about it. I believe that a basic understanding of TTYs in Linux is essential for the developer and the advanced user.

...

In The Hitchhiker's Guide to the Galaxy, Douglas Adams mentions an extremely dull planet, inhabited by a bunch of depressed humans and a certain breed of animals with sharp teeth which communicate with the humans by biting them very hard in the thighs. This is strikingly similar to UNIX,in which the kernel communicates with processes by sending paralyzing or deadly signals to them. Processes may intercept some of the signals, and try to adapt to the situation, but most of them don't.

https://github.com/torvalds/linux/blob/master/drivers/tty/n_tty.c

https://docs.kernel.org/5.17/tty/n_tty.html

https://github.com/torvalds/linux/blob/master/drivers/tty/tty_io.c

https://www.kernel.org/doc/html/v5.8/driver-api/serial/tty.html