[Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED

[Wouter Verhelst]

Hi Lumin,

On Tue, Sep 25, 2018 at 02:40:43PM +0000, Lumin wrote:
> > What I'm emphasizing here is, the debug info in those shared objects
> > are intensionally kept to preserve a good user experience and
> > avoid increasing maintainance burden.
> > 
> > This is the expected backtrace from the code snippet:
> > 
> > > ERROR: could not open file /tmp/y/____nonexistent_file
> > > Stacktrace:
> > >  [1] include at ./boot.jl:317 [inlined]
> > >  [2] include_relative(::Module, ::String) at ./loading.jl:1038
> > >  [3] include(::Module, ::String) at ./sysimg.jl:29
> > >  [4] include(::String) at ./client.jl:388
> > >  [5] top-level scope at none:0
> > 
> > This is the actual backtrace after stripping the shared objects:
> > 
> > > ERROR: could not open file /tmp/y/____nonexistent_file
> > > Stacktrace:
> > >  [1] include(::String) at ./client.jl:388
> > >  [2] top-level scope at none:0
> > 
> > Stripping the shared object is bad to both us Julia maintainers and
> > Julia upstream, because the users is always getting a problematic
> > backtrace and the bug reports will always possibly be problematic.

So tell them to install the debug symbols package and reproduce the bug. You'll
get the expected backtrace then. If they can't figure it out, tell them to send
you their core dump, install the symbols package on your laptop, and
load the core dump with symbols loaded.

There's really no reason to ship debug symbols in the "normal" binary
package in today's world.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
     Hacklab