[Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED
Lumin
cdluminate at gmail.com
Tue Sep 25 15:40:43 BST 2018
hi ftp-master,
Sorry for the noise, but I really care about the package src:julia. And
I started to suspect that ftp-master failed to recieve my last feedback
on the rejection. So I'm re-sending the feedback again, and CCing
-devel to make sure the mail won't get lost.
As of 1.0.0-3 (NEW), this package is nearly ready for the buster release,
and the remaining transition blockers are not in src:julia itself.
So I want to ask ftp-master:
1. Isn't "incomplete backtrace" a sensible reason to keep debug symbols?
Policy said "should" but not "must". Please tell me what I can do in
order to help improve the src:julia package to satisfy the requirements?
2. julia/0.4.7-7+b3 mips64el has been waiting for removal for nearly
a season. In my fuzzy memory julia 0.4.x is also the last blocker
for llvm-3.8 removal. Is there any reason that they should stay
in the archive for longer time?
3. Does ftp-master team extremely lack people such that there isn't
even enough manpower to recruit new members? My ftp-trainee
application mail was not responded for quite a long time again.
I don't really understand what's happending behind the ftp-master
curtain because ftp-master's work is not visible to me. Appologies
if I got something wrong.
Thanks.
On Thu, Aug 23, 2018 at 07:49:09AM +0000, Lumin wrote:
> On Thu, Aug 16, 2018 at 09:55:11PM +0200, Bastian Blank wrote:
> > On Wed, Aug 15, 2018 at 09:48:55AM +0000, Lumin wrote:
> > > > -rw-r--r-- root/root 2093360 2018-08-14 12:28 ./usr/lib/x86_64-linux-gnu/libjulia.so.1.0
> > > This is what I expected and is NOT a mistake.
> > > libjulia.so.1 (symlink) -> libjulia.so.1.1 (ELF shared object)
> >
> > Whoops, I missed the symlink. Usually someone uses the complete
> > version, aka 1.0.0 for the filename.
>
> So there is no problem with the SONAME/SOVERSION or package name.
>
> > > > Please describe directly why you need debug infos.
> > > Justification: Unable to pass unit test without debugging info.
> > > Conclusion:
> > > 1. keeping debugging info makes sense.
> >
> > No. You confuse reason with effect. Some program error is the reason,
> > the failing tests the effect.
>
> At the bottom part of this mail you can find a julia code snippet,
> extracted from Julia's unit test.
>
> 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.
>
> Especially when there is a problem in Julia's internal, such
> incomplete backtrace is really not what we want to see.
>
> Most importantly, policy chapter 10.1 says
>
> > Note that by default all installed binaries should be stripped,
> > either by using the -s flag to install, or by calling strip on the
> > binaries after they have been copied into debian/tmp but before
> > the tree is made into a package.
>
> It is "SHOULD" instead of "MUST".
>
> Is this answer acceptable now?
>
> ----------------------------------------------------------------------------
>
> using Test
> import Libdl
>
> # helper function for returning stderr and stdout
> # from running a command (ignoring failure status)
> function readchomperrors(exename::Cmd)
> out = Base.PipeEndpoint()
> err = Base.PipeEndpoint()
> p = run(exename, devnull, out, err, wait=false)
> o = @async(readchomp(out))
> e = @async(readchomp(err))
> return (success(p), fetch(o), fetch(e))
> end
>
> # backtrace contains type and line number info (esp. on windows #17179)
> for precomp in ("yes", "no")
> succ, out, bt = readchomperrors(`$(Base.julia_cmd()) --startup-file=no --sysimage-native-code=$precomp -E 'include("____nonexistent_file")'`)
> @test !succ
> @test out == ""
> println("DEBUG")
> println(bt)
> println("DEBUG")
>
> @test occursin("include_relative(::Module, ::String) at $(joinpath(".", "loading.jl"))", bt)
> lno = match(r"at \.[\/\\]loading\.jl:(\d+)", bt)
> @test length(lno.captures) == 1
> @test parse(Int, lno.captures[1]) > 0
> end
>
More information about the Pkg-julia-devel
mailing list