On Thu, Jun 24, 2021 at 02:56:16PM -0600, Theo de Raadt wrote:
> > 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
On 2021-06-25, Theo Buehler wrote:
> If we want to go the cherry-picking route, here's a diff that fixes the
> test.csv.gz test case provided in the linked issue.
No objection to this (it won't make a future sync much harder, there
are already many changes in openbsd-zlib compared to the more com
On Thu, Jun 24, 2021 at 10:41 PM Sebastien Marie wrote:
> On Thu, Jun 24, 2021 at 08:04:37PM -0600, Matt Dowle wrote:
> >
> > > It is NOT 16 years old. You keep saying that. There is a different
> > development
> > process involved here which has upsides and downsides and which I don't
> > expe
On Thu, Jun 24, 2021 at 08:04:37PM -0600, Matt Dowle wrote:
>
> > It is NOT 16 years old. You keep saying that. There is a different
> development
> process involved here which has upsides and downsides and which I don't
> expect
> you will understand.
>
> That's right. I don't understand.
> Co
On Thu, Jun 24, 2021 at 11:09:05AM -0600, Matt Dowle wrote:
> Hi,
>
> Is it intentional or is there any good reason that OpenBSD 6.9 released May
> 2021 uses a 16 year old version of zlib (v1.2.3; July 2005)? The latest
> version v1.2.11 (Jan 2017) is 4 years old.
>
> Background here: https://gi
> So feisty.
Seriously?
On Thu, Jun 24, 2021 at 8:33 PM Theo de Raadt wrote:
> Matt Dowle wrote:
>
> > That's right. I don't understand.
> > Could you explain it then, or point me to a document that explains what
> > your development process is?
> > Putting two and two together, it seems that
Matt Dowle wrote:
> That's right. I don't understand.
> Could you explain it then, or point me to a document that explains what
> your development process is?
> Putting two and two together, it seems that it is 16 years plus a bunch of
> cherry picked bug fixes backported over a very many years.
> I don't know either.
> That is what I am asking.
I'm not going to spend more time investigating a bug fix in zlib made 15
years ago. If that's what your policy is, then we have provided plentiful
pointers for you to do so.
> Yes, you keep saying we should just throw the new code in, and you kee
Matt Dowle wrote:
> 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
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/Change
On 2021-06-24, Dave Voutila wrote:
> I'm in 100% agreement it sucks and it's something I believe is already
> done for ports that require OpenSSL.
Only for ports which require OpenSSL and don't require a library
which pulls in LibreSSL. For example we are now stuck on updating
Postfix (thanks to
Dave Voutila wrote:
> Theo de Raadt writes:
>
> > Dave Voutila 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
Theo de Raadt writes:
> Dave Voutila 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 port
On 2021-06-24, Theo de Raadt wrote:
>> 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
Matt Dowle wrote:
> Hi,
>
> Is it intentional or is there any good reason that OpenBSD 6.9 released May
> 2021 uses a 16 year old version of zlib (v1.2.3; July 2005)? The latest
> version v1.2.11 (Jan 2017) is 4 years old.
>
> Background here: https://github.com/Rdatatable/data.table/pull/5049
Dave Voutila 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 comp
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
> 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 ba
Matt Dowle writes:
> Hi,
>
> Is it intentional or is there any good reason that OpenBSD 6.9 released May
> 2021 uses a 16 year old version of zlib (v1.2.3; July 2005)? The latest
> version v1.2.11 (Jan 2017) is 4 years old.
>
> Background here: https://github.com/Rdatatable/data.table/pull/5049
Hi,
Is it intentional or is there any good reason that OpenBSD 6.9 released May
2021 uses a 16 year old version of zlib (v1.2.3; July 2005)? The latest
version v1.2.11 (Jan 2017) is 4 years old.
Background here: https://github.com/Rdatatable/data.table/pull/5049
Best,
Matt
Maintainer of data.ta
20 matches
Mail list logo