[feat] Debian 12 Support #453

Closed
opened 2023-01-26 19:04:08 +00:00 by Ghost · 15 comments

The idea

Debian 12 will be released in a few months. Any plans to support Akkoma with the new release?

The reasoning

I noticed that Akkoma does not work on Debian Testing right now because it does not ship with libcrypt.so.1 anymore.

Have you searched for this feature request?

  • I have double-checked and have not found this feature request mentioned anywhere.
  • This feature is related to the Akkoma backend specifically, and not pleroma-fe.
### The idea Debian 12 will be released in a few months. Any plans to support Akkoma with the new release? ### The reasoning I noticed that Akkoma does not work on Debian Testing right now because it does not ship with libcrypt.so.1 anymore. ### Have you searched for this feature request? - [x] I have double-checked and have not found this feature request mentioned anywhere. - [x] This feature is related to the Akkoma backend specifically, and not pleroma-fe.
Ghost added the
feature request
label 2023-01-26 19:04:08 +00:00
Author

Akkoma doesn't ship anything in regards to OpenSSL libraries. It works fine. You need to install libssl1.1 (openssl-1.1) since the migration to OpenSSL 3.0 dropped libcrypt.so.1 libraries across distros, but a compatibility package exists for most distros.

Akkoma doesn't ship anything in regards to OpenSSL libraries. It works fine. You need to install libssl1.1 (openssl-1.1) since the migration to OpenSSL 3.0 dropped libcrypt.so.1 libraries across distros, but a compatibility package exists for most distros.
Author

How are we supposed to install OpenSSL 1.1 when modern distros no longer support it? Are users expected to compile from source or find a workaround for it? That will be a pain for users. Here is the errors when Akkoma starts with Debian Testing

=ERROR REPORT==== 26-Jan-2023::17:45:17.881225 ===
Unable to load crypto library. Failed with error:
"load_failed, Failed to load NIF library /opt/akkoma/lib/crypto-5.1.2/priv/lib/crypto: 'libcrypto.so.1.1: cannot open shared object file: No such file or directory'"
OpenSSL might not be installed on this system.

=SUPERVISOR REPORT==== 26-Jan-2023::17:45:17.882170 ===
    supervisor: {local,kernel_sup}
    errorContext: start_error
    reason: {on_load_function_failed,crypto,
                {error,
                    {load_failed,
                        "Failed to load NIF library /opt/akkoma/lib/crypto-5.1.2/priv/lib/crypto: 'libcrypto.so.1.1: cannot open shared object file: No such file or directory'"}}}
    offender: [{pid,undefined},
               {id,kernel_safe_sup},
               {mfargs,{supervisor,start_link,
                                   [{local,kernel_safe_sup},kernel,safe]}},
               {restart_type,permanent},
               {significant,false},
               {shutdown,infinity},
               {child_type,supervisor}]


How are we supposed to install OpenSSL 1.1 when modern distros no longer support it? Are users expected to compile from source or find a workaround for it? That will be a pain for users. Here is the errors when Akkoma starts with Debian Testing ``` =ERROR REPORT==== 26-Jan-2023::17:45:17.881225 === Unable to load crypto library. Failed with error: "load_failed, Failed to load NIF library /opt/akkoma/lib/crypto-5.1.2/priv/lib/crypto: 'libcrypto.so.1.1: cannot open shared object file: No such file or directory'" OpenSSL might not be installed on this system. =SUPERVISOR REPORT==== 26-Jan-2023::17:45:17.882170 === supervisor: {local,kernel_sup} errorContext: start_error reason: {on_load_function_failed,crypto, {error, {load_failed, "Failed to load NIF library /opt/akkoma/lib/crypto-5.1.2/priv/lib/crypto: 'libcrypto.so.1.1: cannot open shared object file: No such file or directory'"}}} offender: [{pid,undefined}, {id,kernel_safe_sup}, {mfargs,{supervisor,start_link, [{local,kernel_safe_sup},kernel,safe]}}, {restart_type,permanent}, {significant,false}, {shutdown,infinity}, {child_type,supervisor}] ```
Author

No one's saying you have to build anything yourself. OpenSSL is still maintaining compatibility support for OpenSSL 1.x. All you have to do is follow what I said above: install libssl1.1.

Modern distros support OpenSSL 1.x just fine: by installing libssl1.1 / openssl-1.1

There's nothing for Akkoma to do.

No one's saying you have to build anything yourself. OpenSSL is still maintaining compatibility support for OpenSSL 1.x. All you have to do is follow what I said above: install libssl1.1. Modern distros support OpenSSL 1.x just fine: by installing libssl1.1 / openssl-1.1 There's nothing for Akkoma to do.
Author

Distros DO NOT PROVIDE that package anymore. libssl11.1 has been depreciated. I struggled with other apps that require this also.

Example:

https://askubuntu.com/questions/1408000/unable-to-locate-package-libssl1-1

https://wiki.debian.org/OpenSSL-1.1

So Akkoma needs to address this quickly since they use a depreciated libary that is no longer in the next Stable release of Debian and every other distro.

Distros DO NOT PROVIDE that package anymore. libssl11.1 has been depreciated. I struggled with other apps that require this also. Example: https://askubuntu.com/questions/1408000/unable-to-locate-package-libssl1-1 https://wiki.debian.org/OpenSSL-1.1 So Akkoma needs to address this quickly since they use a depreciated libary that is no longer in the next Stable release of Debian and every other distro.

seconding that there's nothing for us to do

it's the Erlang runtime that requires 1.1

idk how you installed Erlang, if it was via asdf, recompile it

seconding that there's nothing for us to do it's the Erlang runtime that requires 1.1 idk how you installed Erlang, if it was via asdf, recompile it

you didnt specify, but if you're using OTP, the ubuntu-jammy flavour supports sslv3, because of the split

you didnt specify, but if you're using OTP, the ubuntu-jammy flavour supports sslv3, because of the split
Author

I am using the OTP release of Akkoma. Does it need Erlang updated?

I am using the OTP release of Akkoma. Does it need Erlang updated?

use the jammy flavour then, that should work

I'll add on the flavour notes that Debian unstable should use it as well

use the jammy flavour then, that should work I'll add on the flavour notes that Debian unstable should use it as well
Author

OTP releases ship with Erlang though. Users do not install it from the distro repo. This means that Akkoma needs to update the Erlang/Elixer that is bundled with the OTP release right?

OTP releases ship with Erlang though. Users do not install it from the distro repo. This means that Akkoma needs to update the Erlang/Elixer that is bundled with the OTP release right?

as I said, use the jammy OTP flavour - that was bundled specifically to use the sslv3 Erlang runtime
as Ubuntu migrated significantly earlier

as I said, use the jammy OTP flavour - that was bundled specifically to use the sslv3 Erlang runtime as Ubuntu migrated significantly earlier

when v3 goes stable, then the default amd64 build will use the v3 runtime, until then it'll sit in the alternative build

when v3 goes stable, then the default amd64 build will use the v3 runtime, until then it'll sit in the alternative build
Author

Ok, cool Thank you. Is there an ETA for the 3.0 release?

Ok, cool Thank you. Is there an ETA for the 3.0 release?

when it goes stable on Debian

again, the Ubuntu build is already out and should support Debian 12

when it goes stable on Debian again, the Ubuntu build is already out and should support Debian 12

see https://docs.akkoma.dev/stable/installation/otp_en/#detecting-flavour for more information

the Ubuntu build is likely compatible

see https://docs.akkoma.dev/stable/installation/otp_en/#detecting-flavour for more information the Ubuntu build is likely compatible
Author

It works! Thank you very much

It works! Thank you very much
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#453
No description provided.