Theo, > Instead, we got pages and pages that summarize to "must update", and doesn't explain what the bug is or what the fix is.
> If only we had an explanation of what is actually wrong and needs fixing We know it was this news item from 1.2.3.1 (released 16 August 2006) https://zlib.net/ChangeLog.txt : - Take into account wrapper variations in deflateBound() but I don't know which commit that was. We have already worked around it on our side. Yes it would be appreciated if OpenBSD upgraded to zlib 1.2.11 which at 4 years old seems reasonably old. Using a 16-year old version of a library such as zlib, however, seems too old to me: at that age it's starting to become unreasonable to expect other open-source maintainers such as myself to support. Best, Matt On Thu, Jun 24, 2021 at 3:46 PM Theo de Raadt <dera...@openbsd.org> wrote: > Dave Voutila <d...@sisu.io> wrote: > > > Theo de Raadt writes: > > > > > Dave Voutila <d...@sisu.io> wrote: > > > > > >> Theo de Raadt writes: > > >> > > >> >> I think the easiest path here is to incorporate the new upstream > into a > > >> >> port, unless someone is familiar with zlib and can cherrypick out > the > > >> >> commit(s) that resolve the issue. (I didn't find zlib in ports > already.) > > >> > > > >> > That is completely impossible. It must be in base. There are 3 > copies > > >> > in base -- userland, kernel, and bootblocks. They must be kept in > sync. > > >> > > >> Not saying to replace what's in base, but have a different version in > > >> ports available for ports. I was thinking along the lines of egcc or > > >> eopenssl in that the port co-exists with base and ports that need them > > >> need tweaking to use them. > > > > > > You've got to be kidding. In what world does it help to require -I and > > > -l lines all over the place, or else everything breaks. > > > > I'm in 100% agreement it sucks and it's something I believe is already > > done for ports that require OpenSSL. /shrug. My thinking was instead of > > having to test all of base across all archs with any potential fix, we > > could isolate the change to maybe the R port if other R packages or > > whatever have run into this. > > > > But I'm not volunteering to do either so I'll stop beating this horse > > now before it never walks again. > > This is crazy. It is probably a 2-3 line fix. If only we had an > explanation of what is actually wrong and needs fixing... >
