Hi.
Thanks for your reply.
The links to bugs you included add much needed detail to this
discussion.
> "Matthias" == Matthias Klose writes:
Matthias> as pre-processing. So we know since about three years
Matthias> that dwz doesn't support compressed debug symbols. Your
On 2021-03-06 11:11, Jakub Wilk wrote:
* Elana Hashman , 2021-02-17, 11:06:
Would you be able to research some representative slice of popular
packages that would be affected by the policy change (at least 10) and
share the on-disk sizes with compression vs. without?
Not exactly what you
On 3/8/21 6:27 PM, Sam Hartman wrote:
>> "Matthias" == Matthias Klose writes:
>
> Matthias> Maybe you should be more specific about "those who can't
> Matthias> use" uncompressed debug info in the first place.
>
> So, you've argued that the disk savings are not significant inside a
> "Matthias" == Matthias Klose writes:
Matthias> Maybe you should be more specific about "those who can't
Matthias> use" uncompressed debug info in the first place.
So, you've argued that the disk savings are not significant inside a
package, because packages are themselves
On 3/7/21 11:51 PM, Sean Whitton wrote:
> Hello,
>
> On Sun 07 Mar 2021 at 03:50PM -07, Sean Whitton wrote:
>
>> This is not much good if your network is weak or you're offline, or you
>> don't want information on your debugging to go out to a web service.
>
> What I mean is: debuginfod is
Hello,
On Sun 07 Mar 2021 at 03:50PM -07, Sean Whitton wrote:
> This is not much good if your network is weak or you're offline, or you
> don't want information on your debugging to go out to a web service.
What I mean is: debuginfod is great in many scenarios, but we should
probably care about
Hello,
On Fri 05 Mar 2021 at 06:22PM +01, Matthias Klose wrote:
> yes, the rationale for uncompressed debug sections is that any tool can access
> them. On disk as deb/dbgsym package, there is no big difference in
> size.
The data elsewhere in this bug would suggest otherwise!
> Also a
* Elana Hashman , 2021-02-17, 11:06:
Would you be able to research some representative slice of popular
packages that would be affected by the policy change (at least 10) and
share the on-disk sizes with compression vs. without?
Not exactly what you asked Niels for, but...
A few months ago I
yes, the rationale for uncompressed debug sections is that any tool can access
them. On disk as deb/dbgsym package, there is no big difference in size. Also
a debuginfod server can be configured to send the debuginfo compressed on the
fly. The "only" downside is to have the uncomressed
* Elana Hashman:
> You and the original report mention "tooling issues". Can you please
> provide some examples of tools that do not currently support working
> with compressed symbols and the resulting effects on developer workflow?
dwz still can't process compressed debuginfo sections, I
Hi Niels,
Most of the arguments in this and previous bugs are anecdotal. It would
be helpful to provide a concrete analysis of the disk space savings that
compression provides, and whether it is a reasonable default.
There is a discussion about KDE debug symbols requiring 10Gi of disk
space a
Hello Niels,
On Sat 05 Dec 2020 at 01:12PM +01, Niels Thykier wrote:
> The underlying arguments for and against --compress-debug-section appear
> to be "download size" vs. "installed disk usage" vs. "Tooling support".
> Though I ask you to please read the bugs #631985 and #922744 for the
>
Package: tech-ctte
Dear members of the technical committee
I am asking for you provide advice or make a decision according
Constitution 6.1.3 on the matter of whether dbgsym files should use file
level compression or not.
I intend to use the outcome of this bug to determine how to resolve
13 matches
Mail list logo
