On 11/26/20 1:47 PM, PICCORO McKAY Lenz wrote: > seems do you not read the mails, several issues are solved upstream, > but still are happened cos there's no new release. (not so difficult > to make it) > > same for courier, several bug reports are not taken in consideration > (solved of course) and now today make a separate package for maildrop > is nonsense cos is part of courier-mta suite.. it belongs to that > suite, but upstream committed some of the requested features
The question is what the plan of the current maintainer is. He did some work here: https://salsa.debian.org/debian/courier, but didn't do an upload since the beginning of 2019. Regards Racke > > El jue, 26 de nov. de 2020 a la(s) 07:56, Josip Rodin > (j...@debbugs.entuzijast.net) escribió: >> >> >> Why are you posting these agitated bug reports? Can I suggest that you first >> calm down and try to compose your thoughts, and then put that in writing >> while bearing in mind that an assumption of good faith is the only proper >> way to operate? >> >> On Mon, Nov 16, 2020 at 04:08:21AM -0400, PICCORO McKAY Lenz wrote: >>> Package: maildrop >>> Version: 2.9.3-2 >>> Severity: important >>> >>> The maildrop package in debian is severely out of sync and outdated: >>> >>> First of all stop of "Upstream is not willing to add another feature", >>> seems people dont understan maildrop are made for courier, and if need >>> can proposed a fork for that! >>> >>> Second: **several problems where aborted upstream**, the most >>> important ones are: >>> * libs/maildrop/deliver.C (delivery): Always return 75 upon >>> delivery failure, for the standalone maildrop build. related to #481223 >>> * libs/maildir/maildirmake.c (main): maildirmake's -q option >>> will create the maildir if it does not exist. related to #501557 >>> * libs/rfc2045/reformime.c (main2): Fix crash when the -s option is >>> not valid. related to #71625 >>> * rfc2045/reformime.c (main2): fix crash if -x or -X is specified >>> without the corresponding -s option. related to #71625 >>> >>> A new maildrop pack is required and this must either come from the >>> same courier sources (#867121) or update the one... this last seems >>> quite stupid as courier is the official sources of maildrop and >>> although it is offered separately by the author upstream, unifying it >>> will improve maintenance from a team, and as you guys notice lack of >>> interest/avaliable time in the courier suite (reading the last >>> changelog, seems changes are more to complain with debian package >>> policy that is innecesary respect real issues) >>> >>> ... and as far as I can see you are looking for the sources in sf >>> instead of the right place which is the courier oficial download page, >>> additional while the courier-mta sources are up to date in >>> salsa-debian, the maildrop one in salsa-debian are too old respect the >>> mta suite! >>> >>> while I made my own package on OBS vegnuli home for Devuan and Debian, >>> is you guys need help i'm a often user of the complete suite and not >>> just parts or toys of, maildrop can be build with two ways: >>> * set GID mail without restricted caller (maildrop) >>> * set UID root with restricted caller for courier-mta >>> (maildrop-courier) -- missing and the way i set in my package cos >>> is the need by the original suite the courier-mta >>> >>> >>> NOTE: Courier maildrop in debian present a very not proper behaviour.. >>> original sources are from courier and any other implementation are >>> non-related and users can fork the software, cases like #375589 are >>> not valid cos seems maildrop (as author make it for courier filtering) >>> is a courier implementation if applies! so any external specific usage >>> are purely optional >>> >>> This are related to #910380 (separate makemime from sources) #204187, >>> #596057 & #375589#26 (bad usage cos is not made for), #481223 >>> (changed behaviour cos is not made for, what?), #592585 (dovecot >>> specific crap) and go and go.. seems people thinks that maildrop are >>> made for others rather than the courier suite... funny please close >>> all of those package cos seems many of them are not supported by >>> upstream and community must make a fork in those several cases! >>> >>> Lenz McKAY Gerardo (PICCORO) >>> http://qgqlochekone.blogspot.com >> >> -- >> Josip Rodin > > -- Ecommerce and Linux consulting + Perl and web application programming. Debian and Sympa administration. Provisioning with Ansible.
OpenPGP_signature
Description: OpenPGP digital signature
