the changelog does not take in consideration the amount of bugs reports.. seems do not read all ( i read all the issues, inclusively ask some to upstream and read carefully about the maildrop hole issue)
also there's a new unicode release that fixed the BROKEn cone package that are not taken in consideration El jue, 26 de nov. de 2020 a la(s) 09:40, Stefan Hornburg (Racke) (ra...@linuxia.de) escribió: > > 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. >
