Is there some reason this hasn't been pushed to stable?

This update caused perl-Math-BigInt-GMP to become FTBFS: https://apps.fedoraproject.org/koschei/package/perl-Math-BigInt-GMP?collection=f35

Please add updated build perl-Math-BigInt-GMP-1.6010-1.fc35 to this update.

Ah, I have cockpit-ws installed since I'm using Fedora Server, and that's what broke things even though I'm not actually using cockpit myself?

This is much better for me but I'm not using cockpit so I'll defer karma until someone mentions that cockpit's OK.

This update broke a local policy module I have:

# semodule -i smfs.pp
Problems processing filecon rules
Failed post db handling
Post process failed
semodule:  Failed!

Module:

# more smfs.fc smfs.if smfs.te
::::::::::::::
smfs.fc
::::::::::::::
/usr/sbin/smf-sav   --  gen_context(system_u:object_r:smf_sav_milter_exec_t,s0)
/usr/sbin/smf-spf   --  gen_context(system_u:object_r:smf_spf_milter_exec_t,s0)

/var/run/smfs(/.*)?     gen_context(system_u:object_r:smfs_milter_data_t,s0)
::::::::::::::
smfs.if
::::::::::::::
## <summary>Smart Mail Filter milters</summary>

########################################
## <summary>
##  "Smart Mail Filter" suite variant of milter template.
## </summary>
## <param name="milter_name">
##  <summary>
##  The name to be used for deriving type names.
##  </summary>
## </param>
#
template(`smf_milter_template',`

    milter_template(smf_$1)

    # Milters remove any existing socket (not owned by root) whilst running as root
    # and then call setgid() and setuid() to drop privileges
    allow smf_$1_milter_t self:capability { setuid setgid dac_override };

    # Look up username for dropping privs
    auth_use_nsswitch(smf_$1_milter_t)

    # Allow communication with MTA over a unix-domain socket
    # Note: usage with TCP sockets requires additional policy
    manage_sock_files_pattern(smf_$1_milter_t, smfs_milter_data_t, smfs_milter_data_t)

    # Config is in /etc/mail/smfs/smf-*.conf
    mta_read_config(smf_$1_milter_t)

    # Create other data files and directories in the data directory
    manage_files_pattern(smf_$1_milter_t, smfs_milter_data_t, smfs_milter_data_t)
')
::::::::::::::
smfs.te
::::::::::::::
policy_module(smfs, 0.0.9)

########################################
#
# Declarations
#

smf_milter_template(sav)
smf_milter_template(spf)

# /var/run/smfs is shared by smf milters
type smfs_milter_data_t, milter_data_type;
files_pid_file(smfs_milter_data_t)

########################################
#
# smf-sav local policy
#

allow smf_sav_milter_t self:netlink_route_socket rw_netlink_socket_perms;
allow smf_sav_milter_t self:tcp_socket create_stream_socket_perms;
allow smf_sav_milter_t self:udp_socket create_socket_perms;

# It makes outbound SMTP connections to verify addresses
corenet_tcp_connect_smtp_port(smf_sav_milter_t)

sysnet_read_config(smf_sav_milter_t)

########################################
#
# smf-spf local policy
#

# (no additional policy needed - template is sufficient)

Module had been unchanged for years. Downgrading selinux-policy back to selinux-policy-35.9-1.fc35 and reinstalling the module fixed it.

Please push this to stable; it's needed by perl-MCE, which is already stable. No problems seen in test suites of Sereal.

Please push this to stable; it's needed by perl-MCE, which is already stable. No problems seen in test suites of Sereal.

Sereal builds fine using this.

Sereal builds fine using this.

I already built perl-Module-Install-GithubMeta-0.30-17.el9 and created an update for it, which also included perl-Module-Install-AutoLicense-0.10-6.el9 (https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e06fdd1b8d). I guess I need to unpush my update and you can add perl-Module-Install-AutoLicense-0.10-6.el9 to this one? Do you concur?

Fixes most of the SELinux issues but as I use some non-default jails, I also get these:

type=AVC msg=audit(1623327223.709:6536): avc:  denied  { watch } for  pid=118968 comm="fail2ban-server" path="/var/log/secure" dev="dm-0" ino=662190 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=0
type=AVC msg=audit(1623327223.713:6537): avc:  denied  { watch } for  pid=118968 comm="fail2ban-server" path="/var/log/httpd" dev="dm-0" ino=658553 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:httpd_log_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1623327223.713:6538): avc:  denied  { watch } for  pid=118968 comm="fail2ban-server" path="/var/log/httpd/access_log" dev="dm-0" ino=662142 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:httpd_log_t:s0 tclass=file permissive=0

I'm going to have to downgrade my bacula server back down to 9.x because this version requires a significant database update as described in the release notes, and the database upgrade script for mysql is not working for me (I'm currently on database version 16 and the script is failing to remove index JobId on the File table).

The App-Cme issue looks like a valid warning (for a duplicate "verbose" option), which was added recently.

https://github.com/rjbs/Getopt-Long-Descriptive/commit/8f8a608af6bb4b3507bd80df057738822bb1ecab

GLD 0.106 introduced use of Term::ReadKey to get the terminal width, so it was necessary to run tests in "expect" to get them to work. This caused a lot of problems like the ones you saw, so GLD 0.107 reverts that change.

proftpd is a server, not a client. You start it by doing:

$ sudo systemctl start proftpd

You can check its status by doing:

$ sudo systemctl status proftpd

It looks like your last attempt at starting it via sudo worked, so you may need to kill that one if it's still running.

@jpbn, I installed this on a fresh F32 box and it worked straight away for me. Have you made any changes to the way the server is started? If you run rpm -V proftpd does it report anything other than /etc/ftpusers?

What do you get from ls -lZ /etc/proftpd.conf?

Here's what I get:

[root@tycho ~]# ls -lZ /etc/proftpd.conf 
-rw-r-----. 1 root root system_u:object_r:ftpd_etc_t:s0 6485 May 31 17:35 /etc/proftpd.conf
[root@tycho ~]# rpm -V proftpd
S.5....T.  c /etc/ftpusers
[root@tycho ~]# ls -lZ /etc/proftpd.conf 
-rw-r-----. 1 root root system_u:object_r:ftpd_etc_t:s0 6485 May 31 17:35 /etc/proftpd.conf

Is there a reason this update isn't being pushed to stable?

Update details: "Rebased to version 2.5.2"? A bit of finger trouble there...