We plan to release YunoHost 11 as stable in the next days, please test it :)

I think we are talking about this package: GitHub - YunoHost-Apps/mailman_ynh: Mailman packaging for YunoHost

1 Like

This is good to know! I am just eager to find out if something breaks when I update.
I have made slight modifications to a bunch of template files in /etc/nginx/conf.d/

Fingers crossed and happy upgrading!!!

1 Like

Well, mailman in itself may be used by other apps, but the main point is to host mailman on a YNH instance, so as to provide mailing-list, per se. The YNH machine being able to receive and send email is then managing the lists. Mailman is integrated with postfix, etc.

2 Likes

More specifically, one can refer to GitHub - YunoHost-Apps/mailman_ynh: Mailman packaging for YunoHost :

Mailman2 is a deprecated software : it relies on Python 2 which reached end of life in January 2020. Mailman 2 is not being developed anymore, and wont be available on Debian Bullseye / Yunohost 11.x. You should really consider using alternative solutions.

The replacement being GitHub - YunoHost-Apps/mailman3_ynh: Mailman - The GNU Mailing List Management System packaged for YunoHost.

Hth,

1 Like

Is mailman an issue to anyone? Can’t we just use mailman3 instead?

Can it be an issue if the boilerplate templates are modified in the above directory when migrating to Debian 11? I modified the files to remove the logo in the bottom right.

We have a global setting for that. [opinion] there should be an option to remove the logo on atleast the apps that anonymous users can see (aka front facing sites) - #7 by metyun (yes, it is not documented :sweat_smile:, but a future feature will make them available in the webadmin)

2 Likes

Re Mailman 3 vs Mailman 2, the thing is that you need to plan a transition of one to the other, and I’m not sure there’s a smooth migration path, both software being merely different. I.e. backup + restore, reconfigure, etc.
Also, the user experience will be different : need to plan supporting their learning of how to reach the new location, change of habits, etc.

Release notes should address that, then, IMHO

This appears to be a Debian 11 specific question and the incompatibility isn’t caused by yunohost. This might be the first time where I have seen a linux application which isn’t forward compatible to a future linux OS bistro. This is so strange!!! What inside of linux is stopping the app to be compatible?

1 Like

Migrating from Mailman 2.1 to Mailman 3 — Mailman Suite 3.3 documentation may provide more details.

Me waiting for the new Yunohost, I finally have my own vps so I can install Debian 11 with Yunohost. When does the curl command come public?

1 Like

Just now I tried another installation of yunohost on Raspios 64bit (beta stage testing), using the latest bullseye lite 4.4.2022 on a raspi 4b8gb and raspi 3b+

Compared to my old installation on raspi bullseye arm64 some weeks ago - which still seems to work - there is no difference.
My Primary Apps: roundcube and nextcloud

systemctl still says: rspamd.service is loaded/failed/failed (and diagnosis tells me that every day at 7AM and 7PM)
and systemctl complained formerly: user@1007.service: loaded/failed/failed
what changed in the new install to: user@1000.service: loaded/failed/failed

When you go back in the testing discussion some weeks there was a very emotional answer to a user who installed rspamd from sid, what was working for him, while the one from bullseye did not. Since then I could not find a real solution.

I think I should wait with the final installation until the two errors in systemctl are gone – right?

I wonder how will the upgrade be? We will have to first push an upgrade to Debian from 10 to 11, or is the Yunohost going to force that when we get an update for YNH 11? I have plenty of apps and I wonder if this process will be more automated or I will have to reinstall Debian 11 and then Yunohost 11 and all apps individually…

1 Like

@Tio You can find instructions that will be added in the doc the day of the release: doc/buster_bullseye_migration.md at refactor-admin-guide · YunoHost/doc · GitHub

2 Likes

Thank you. You guys are doing an amazing work with Yunohost. I am a bit concerned about this big upgrade but backups are our friends.

1 Like

Could you give logs about this rspamd failure ?

I add a ticket about a probable rspmad error with rpi64.

I am not sure to know what it really means

@Dutch84 If you want to test a new install of a fresh YunoHost on top of a fresh Debian 11/Bullseye then you just have to do :

$ wget https://install.yunohost.org/bullseye -O install_script
$ bash install_script -d testing
1 Like

I like to wait for the stable version to install, I don’t have enough knowledge to fix problems.

2 Likes

Hello,

I am new to both Yunohost and Wireguard, but I am reporting the following in case it could relate to the current debugging effort.

I have just installed YNH testing branch using the install script on a fresh Debian 11.3 VPS (KVM) with kernel 5.10.0-14-amd64. It worked perfect.
Then I have installed the Wireguard package via YNH web admin interface and got the following error message:

Packagers: ynh_add_app_dependencies is deprecated and is now only an alias to ynh_install_app_dependencies
wg-quick.target is a disabled or a static unit, not starting it.
Loading new wireguard-1.0.20210219 DKMS files...
Building for 5.10.0-8-amd64 5.10.0-14-amd64
Module build for kernel 5.10.0-8-amd64 was skipped since the kernel headers for this kernel does not seem to be installed.
Building initial module for 5.10.0-14-amd64
Error! The /var/lib/dkms/wireguard/1.0.20210219/5.10.0-14-amd64/x86_64/dkms.conf for module wireguard includes a BUILD_EXCLUSIVE directive which does not match this kernel/arch. This indicates that it should not be built.
Skipped.

There’s no “5.10.0-14-amd64” folder in “1.0.20210219” folder, but there is a dkms.conf at /var/lib/dkms/wireguard/1.0.20210219/source/dkms.conf which contains:

PACKAGE_NAME="wireguard"
PACKAGE_VERSION="1.0.20210219"
AUTOINSTALL=yes

BUILT_MODULE_NAME="wireguard"
DEST_MODULE_LOCATION="/kernel/net"


if ls /lib/modules/5.5*/source/include/uapi/linux/wireguard.h >/dev/null 2>&1 ; then
    # debian backported wireguard into the 5.5 release:
    BUILD_EXCLUSIVE_KERNEL="^((5\.[0-4]($|[.-]))|(4\.)|(3\.1[0-9]))"
else
    # upstream requires kernel 3.10 - 5.5, inclusive:
    BUILD_EXCLUSIVE_KERNEL="^((5\.[0-5]($|[.-]))|(4\.)|(3\.1[0-9]))"
fi

I can nevertheless access Wireguard’s unofficial webUI without any glitch.
Since I havn’t been further in WG config yet, I cannot tell so far whether it actually works. But I noted - launching diagnosis command within YNH - a related error about port 8095 apparently closed from outside with a warning saying that it is necessary for wg-quick@wg0 to work properly. The diagnosis also reports that service wg-quick@wg0 failed to start, due to /etc/wireguard/wg0.conf not existing, but i assume that this is because I have not finished the configuration phase yet.

Thank you for testing. Regarding the dkms issue, it should be fixed with a testing version of the app that is waiting the release of YunoHost 11.

Problem known and not critical, cf. the app’s Github issues or maybe even WireGuard thread here.

You assume correctly.:slight_smile: Report back after configuring it and hitting "Apply config " in the webUI.

1 Like