From phk at phk.freebsd.dk  Mon Aug 23 08:57:51 2021
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 23 Aug 2021 08:57:51 +0000
Subject: Death on idea: filters on synth bodies
Message-ID: <202108230857.17N8vpCL047249@critter.freebsd.dk>

For the longest times I have wanted to run synth bodies through
VFP, to get rid of the temp VSB and to enable ESI processing
on error messages.

It is not going to happen.

It would become quite a mess in `vcl_synth{}`.

We do not run `vcl_deliver{}` after `vcl_synth{}, so there
both the VFP and VDP filter lists would have to be configured
at the same time, which in addition to requiring two filter
lists variables, makes it near impossible to produce the automatic
proposal for VDP filters based on the object.

But we would also still have to buffer the body in a VSB, because we
"suck" data through VFP from the core code, we dont push it in from
the fetch code.

It would be more feasible to do it in the case of `vcl_backend_error{}`
because we only need to deal with the VFP list there, but the temporary
VSB would still be required there too.

So, yeah:  Not going to happen.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

From geoff at uplex.de  Tue Aug 24 14:39:49 2021
From: geoff at uplex.de (Geoff Simmons)
Date: Tue, 24 Aug 2021 16:39:49 +0200
Subject: Packaging: why does the RPM spec have both Provides & Obsoletes for
 the same packages?
Message-ID: <1f744e1d-f7bf-6b87-19b2-fa0d532fac93@uplex.de>

Hello,

The spec file for RPM packages:

https://raw.githubusercontent.com/varnishcache/pkg-varnish-cache/master/redhat/varnish.spec

... has this passage:

Provides:  varnish-libs%{?_isa} = %{version}-%{release}
Provides:  varnish-libs = %{version}-%{release}
Obsoletes: varnish-libs

Provides:  varnish-docs = %{version}-%{release}
Obsoletes: varnish-docs

Provides:  varnish-debuginfo%{?_isa} = %{version}-%{release}
Provides:  varnish-debuginfo = %{version}-%{release}
Obsoletes: varnish-debuginfo

This may be an RPM technique that I'm not familiar with, but why does it
have both Provides and Obsoletes for -libs, -docs and -debuginfo?

Since the Obsoletes don't specify a version, my best guess is that it's
something about updating to newer versions. But wouldn't newer versions
(newer version and RPM release number) be enough for that?

Asking because I'm building a custom RPM package for which I'd also like
to have the debuginfo. Creating the debuginfo RPM is easy enough, by
removing this line from the spec:

%global debug_package %{nil}

But then when you try to run debuginfo-install, it says that the
debuginfo package is obsoleted by the Varnish package.

I can get the debuginfo to install by removing the Obsoletes line for
varnish-debuginfo, and rebuilding the RPMs. But I'm confused about why
it was there in the first place, and concerned that I may have broken
something else by doing so.


Thanks,
Geoff
-- 
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstra?e 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20210824/ec1cf7da/attachment.bin>

From dridi at varni.sh  Tue Aug 24 16:36:36 2021
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Tue, 24 Aug 2021 16:36:36 +0000
Subject: Packaging: why does the RPM spec have both Provides & Obsoletes
 for the same packages?
In-Reply-To: <1f744e1d-f7bf-6b87-19b2-fa0d532fac93@uplex.de>
References: <1f744e1d-f7bf-6b87-19b2-fa0d532fac93@uplex.de>
Message-ID: <CABoVN9C2XP-RTwHuhw3YuZL7Ff5K8ZdMQ=Me54coyVj3JsT58A@mail.gmail.com>

Hey Geoff,

On Tue, Aug 24, 2021 at 2:40 PM Geoff Simmons <geoff at uplex.de> wrote:
>
> Hello,
>
> The spec file for RPM packages:
>
> https://raw.githubusercontent.com/varnishcache/pkg-varnish-cache/master/redhat/varnish.spec
>
> ... has this passage:
>
> Provides:  varnish-libs%{?_isa} = %{version}-%{release}
> Provides:  varnish-libs = %{version}-%{release}
> Obsoletes: varnish-libs
>
> Provides:  varnish-docs = %{version}-%{release}
> Obsoletes: varnish-docs
>
> Provides:  varnish-debuginfo%{?_isa} = %{version}-%{release}
> Provides:  varnish-debuginfo = %{version}-%{release}
> Obsoletes: varnish-debuginfo
>
> This may be an RPM technique that I'm not familiar with, but why does it
> have both Provides and Obsoletes for -libs, -docs and -debuginfo?
>
> Since the Obsoletes don't specify a version, my best guess is that it's
> something about updating to newer versions. But wouldn't newer versions
> (newer version and RPM release number) be enough for that?

They should ideally provide a version, but since we have packaging
that could compete with first party packages we can't really predict
what version we would go against.

Keeping Provides doesn't break an installation of -docs for example,
because ultimately the package containing the docs is going to be
installed thanks to the Provides.

> Asking because I'm building a custom RPM package for which I'd also like
> to have the debuginfo. Creating the debuginfo RPM is easy enough, by
> removing this line from the spec:
>
> %global debug_package %{nil}
>
> But then when you try to run debuginfo-install, it says that the
> debuginfo package is obsoleted by the Varnish package.
>
> I can get the debuginfo to install by removing the Obsoletes line for
> varnish-debuginfo, and rebuilding the RPMs. But I'm confused about why
> it was there in the first place, and concerned that I may have broken
> something else by doing so.

I think the reason why we didn't want the traditional separation
debuginfo package was the poor quality of panic backtraces. Once
split, installing the separate debuginfo wouldn't improve the
backtraces.

I think this specific point was a result of:

https://github.com/varnishcache/varnish-cache/commit/95437e6c882f2c2b332be94060a7ac96907db322

It's been a while, I don't remember the details.

Cheers,
Dridi

From geoff at uplex.de  Tue Aug 24 17:55:10 2021
From: geoff at uplex.de (Geoff Simmons)
Date: Tue, 24 Aug 2021 19:55:10 +0200
Subject: Packaging: why does the RPM spec have both Provides & Obsoletes
 for the same packages?
In-Reply-To: <CABoVN9C2XP-RTwHuhw3YuZL7Ff5K8ZdMQ=Me54coyVj3JsT58A@mail.gmail.com>
References: <1f744e1d-f7bf-6b87-19b2-fa0d532fac93@uplex.de>
 <CABoVN9C2XP-RTwHuhw3YuZL7Ff5K8ZdMQ=Me54coyVj3JsT58A@mail.gmail.com>
Message-ID: <09e2a1a2-bea4-3249-bb53-de192f6a474e@uplex.de>

On 8/24/21 18:36, Dridi Boukelmoune wrote:
> 
> They should ideally provide a version, but since we have packaging
> that could compete with first party packages we can't really predict
> what version we would go against.

Got it.

> I think the reason why we didn't want the traditional separation
> debuginfo package was the poor quality of panic backtraces. Once
> split, installing the separate debuginfo wouldn't improve the
> backtraces.

OK ... hmmm. My experience has been that the information available in a
panic's stack trace, or to gdb for a coredump, has been relatively
barren. The binary isn't stripped, so you can see function names, but
that's about it, everything else is mostly question marks and hex digits.

Assertions are an exception, of course, because the names and source
code line are in the string. But otherwise we have sometimes resorted to
deciphering addresses and offsets and disassembled code. That can get
you surprisingly far, but it could be so much easier.

With the debuginfo installed, I could see everything in gdb, just the
way you like it.

Dridi thanks for the info, I won't worry about the debuginfo disrupting
something else. Since it seems to work well, maybe the Varnish project
can consider putting debuginfo RPMs on packagecloud as well? Like I
said, I couldn't get it to install without removing the Obsoletes line,
so that would have to be cleared up.

PR or issue for pkg-varnish-cache?


Best,
Geoff
-- 
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstra?e 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20210824/2012bada/attachment.bin>

From dridi at varni.sh  Tue Aug 24 20:34:53 2021
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Tue, 24 Aug 2021 20:34:53 +0000
Subject: Packaging: why does the RPM spec have both Provides & Obsoletes
 for the same packages?
In-Reply-To: <09e2a1a2-bea4-3249-bb53-de192f6a474e@uplex.de>
References: <1f744e1d-f7bf-6b87-19b2-fa0d532fac93@uplex.de>
 <CABoVN9C2XP-RTwHuhw3YuZL7Ff5K8ZdMQ=Me54coyVj3JsT58A@mail.gmail.com>
 <09e2a1a2-bea4-3249-bb53-de192f6a474e@uplex.de>
Message-ID: <CABoVN9CN+Ed4K5CNNQEgMmxvuOcSZoBc6+h46YjUDm-0FXC-oA@mail.gmail.com>

> OK ... hmmm. My experience has been that the information available in a
> panic's stack trace, or to gdb for a coredump, has been relatively
> barren. The binary isn't stripped, so you can see function names, but
> that's about it, everything else is mostly question marks and hex digits.
>
> Assertions are an exception, of course, because the names and source
> code line are in the string. But otherwise we have sometimes resorted to
> deciphering addresses and offsets and disassembled code. That can get
> you surprisingly far, but it could be so much easier.
>
> With the debuginfo installed, I could see everything in gdb, just the
> way you like it.

What I meant is, once the debuginfo was split in its own package we
would lose symbol names in the backtrace whether or not the mathing
debuginfo package was installed.

At the time we didn't have libunwind support and I suspect it might solve
this problem if it still exists. The quality of libunwind backtraces is clearly
higher.

I experimented with libdwarf to add the source file, source line (sometimes
off by one) and binary file. Including VMODs! But well, that's an extra
dependency and a fair amount of additional panic code...

> Dridi thanks for the info, I won't worry about the debuginfo disrupting
> something else. Since it seems to work well, maybe the Varnish project
> can consider putting debuginfo RPMs on packagecloud as well? Like I
> said, I couldn't get it to install without removing the Obsoletes line,
> so that would have to be cleared up.
>
> PR or issue for pkg-varnish-cache?

PR is probably better, once we agree on an outcome the change is just
a few clicks away from being merged :)

I would love to default to libunwind but last time we brought this up the
idea was shot down, but, something tells me that it would stand a better
chance today.

Cheers