Dear Hodek, have you found a workaround to manage your cron jobs?
Let me summarize the current situation: - you raised bug report 1020415 three months ago, based on your experience with bcron version 0.11-9, which is part of debian/stable aka bullseye; version 0.11-9 has been released in March 2020, so it was more than two years ago (the upload was made by Dmitry Bogatov, signed by Andreas Henriksson) - both of us could check that this version is buggy, and cannot be launched properly by systemd within a debian/bullseye system - I took the responsability of this package in June 2022, and uploaded some new releases (0.11.10 to 0.11-17). bcron 0.11-17 migrated to debian/testing on Tue, 28 Jun 2022. Those changes allowed me to close a few bugs (#983799, #984576 and #1012852), and introduce a pre-dependency from bcron to cron-daemon-common, in order to enable users to switch easier between cron, bcron and cronie in the future. At that time, nobody complained about bcron's wrong startup. - I am receiving now repeated warnings from Ubuntu's automaton, which states that the last version of bcron cannot entrer Ubuntu's future stable release. Here are a few possible reactions: - I can orphan the package bcron (it would be orphaned twice!) - I can raise a RFH (request for help) bugreport ... and hope. - I can try to enforce the postinst, prerm and postrm scripts which did work within debian/buster, and inhibit the normal build of the package, regarding dh_sysuser and dh_runit, as you could check that launching bcron by hand was effective. If I do so, I must prominently state for future users than bcron must be considered as obsolete, and recommend using cron (or cronie in the future?) Any thoughts? Thank you in advance for your feedback. Best regards, Georges.
signature.asc
Description: PGP signature
