Entware Entware armv7sf-k2.6 EOS

[garycnew]

@thelonelycoder I ran into an issue, attempting to use python's ssl (python3-openssl) module, with the armv7sf-k2.6 repo's, in that ssl appears to function properly with the entware and garycnew repos' python3-openssl packages, but doesn't seem to work with the maurer repo's python3-openssl package.

entware:

# python -c "import ssl; print(ssl.OPENSSL_VERSION)"
OpenSSL 3.0.10 1 Aug 2023
# openssl version
OpenSSL 1.1.1w  11 Sep 2023

maurer:

# python -c "import ssl; print(ssl.OPENSSL_VERSION)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/lib/python3.11/ssl.py", line 100, in <module>
ImportError: /opt/lib/python3.11/lib-dynload/_ssl.cpython-311-arm-linux-gnueabi.so: symbol COMP_get_type, version OPENSSL_3.0.0 not defined in file libcrypto.so.3 with link time reference

garycnew:

# python -c "import ssl; print(ssl.OPENSSL_VERSION)"
OpenSSL 3.0.14 4 Jun 2024
# openssl version
OpenSSL 1.1.1w  11 Sep 2023

I'm trying to understand whether it's strictly an issue with maurer's repo, an issue with mixed packages from the combination of armv7sf-k2.6 repo's, or something else.

If you could attempt to reproduce each case, I would be greatly appreciative.

Respectfully,


Gary

 

[garycnew]

@thelonelycoder

In addition to Maurer discontinuing their armv7sf-k2.6 repo, the primary reason I decided to take-up the torch to continue building an armv7sf-k2.6 repo is because Maurer's repo lacked some of the packages (nmap-full) and depenencies (liblua-5.4) that I needed and felt it would be more stable building my own stack.

While the garycnew repo is now the primary backport used (when enabled), I'm concerned that combining the entware base, maurer, and garycnew backport repos may lead to dependency conflicts and issues. The Entware dependency logic is fairly rudimentary and only looks to see whether the dependent package exists and sometimes requires a specific version.

Would it be possible to modify amtm (when enabled) to specify a particular backport repo; similar, to the entware base repo? I believe it would be better to stick within a backport repo where applications and dependencies were built for one another. Moreover, if someone wants to add an alternative package, they can download and add the package manually, at their sole discretion, to confirm whether it works or not.

I appreciate your consideration.

Respectfully,


Gary

 

[thelonelycoder]

Would it be possible to modify amtm (when enabled) to specify a particular backport repo; similar, to the entware base repo? I believe it would be better to stick within a backport repo where applications and dependencies were built for one another. Moreover, if someone wants to add an alternative package, they can download and add the package manually at their sole discretion to confirm whether it works or not.

I appreciate your consideration.

I rely on your expertise and far better judgement. Therefore, I am going to drop maurers backport for these routers, as originally mentioned and suggested by you.
I appreciate your commitment and determination for this project.

 

[thelonelycoder]

amtm 6.1.2 is now out.

 

[garycnew]

I rely on your expertise and far better judgement. Therefore, I am going to drop maurers backport for these routers, as originally mentioned and suggested by you.
I appreciate your commitment and determination for this project.

I'm open to dissenting opinions in the matter, but I believe... "This is the way."

Thanks, @thelonelycoder

Ditto

 

[garycnew]

Just to clarify, is the “tailscale” version here the normal one for more recent routers and the “tailscale_nohf” version for armv7sf-k2.6 based devices such as the RT-AC68U?

@jksmurf

I found myself needing to know the answer to this question. It appears HF is for CPU's that support Hardware Floating Pointer calculations and NOHF is for CPU's that do not and preform the calculations by way of software.

As the armv7l CPU (`uname -m`) does not contain the term "fpu" within the `cat /proc/cpuinfo` output; thus, it makes use of NOHF (Software Floating Pointer) packages.

Hope that helps.

Regards,


Gary

 

[garycnew]

@thelonelycoder

I found a couple more examples of when dependency conflicts between the entware and garycnew repo's exist:

Installing libpcre (8.45-5) to root...
Downloading https://bin.entware.net/armv7sf-k2.6/libpcre_8.45-5_armv7-2.6.ipk

Installing libpcre2 (10.42-1) to root...
Downloading https://garycnew.github.io/Entware/armv7sf-k2.6/libpcre2_10.42-1_armv7-2.6.ipk

AND

Installing libsqlite3 (3410200-1) to root...
Downloading https://bin.entware.net/armv7sf-k2.6/libsqlite3_3410200-1_armv7-2.6.ipk

Installing libsqlite3 (3.49.1-2) to root...
Downloading https://garycnew.github.io/Entware/armv7sf-k2.6//libsqlite3_3.49.1-2_armv7-2.6.ipk

Most of the garycnew repo apps depend on libpcre2 (not libpcre) and the libsqlite3 versioning is such that entware thinks the old 3410200-1 is greater than 3.49.1-2 (which it is clearly not).

I manually removed the entware repo from my /opt/etc/opkgs.conf, made the garycnew repo the base repo, and it all seems to work.

Respectfully,


Gary

 

[jksmurf]

@jksmurf

I found myself needing to know the answer to this question. It appears HF is for CPU's that support Hardware Floating Pointer calculations and NOHF is for CPU's that do not and preform the calculations by way of software.

As the armv7l CPU (`uname -m`) does not contain the term "fpu" within the `cat /proc/cpuinfo` output; thus, it makes use of NOHF (Software Floating Pointer) packages.

Hope that helps.

Regards,


Gary

Very good, that's a nice concise explanation, much appreciated.

The sample size of users who will benefit from it may be very small, but maybe (and there are still a few) someone will just plonk Tailmon on an old RT-AC68U Router to bypass CGNAT or something and this is for them. Awesome job, thank you.

k.