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

[Mo Zhou]

Hi,

We (Julia maintainers) reached an agreement to revert the name of NEW
binary package "libjulia1" back to "libjulia0.7", and upload the ugly
package to unstable after a week or ten days, in order to bypass the NEW
queue process. Resulting lintian Errors will be simply ignored.

I'm declaring this in advance, so if anyone see something dirty happend
on the Julia binary packages, please don't report any bug against that
dirty solution.

Of course, immediately after the upload of the dirty package, I'll
re-upload a clean one (shipping NEW "libjulia1") to NEW queue.

Only in this way can I get rid of the fear that Julia wouldn't enter
Buster in time... Sigh...

On Mon, Dec 17, 2018 at 12:38:25PM +0000, Mo Zhou wrote:
> Hi,
> 
> Another fortnight has passed. Any update?
> 
> I've just uploaded Julia 1.0.3 to the NEW queue. This time the ordinary
> shared object libjulia.so.1 is also stripped. Julia's sysimage sys.so
> should be regarded as a special case and will never be stripped.
> 
> 
> On Fri, Nov 30, 2018 at 02:55:55PM +0000, Mo Zhou wrote:
> > Hi Bastian,
> > 
> > I've uploaded julia_1.0.2-1 to unstable (NEW) yesterday. There are
> > already six uploads being piled up in NEW. These uploads already have
> > been tested by Ubuntu devel extensively, and are suitable for the
> > Buster release.
> > 
> > I totally understand that for traditional C/C++ shared object, stripping
> > debugging information makes sence for our archive, and I'm really
> > stripping my every other C/C++ shared objects in other packages. However
> > I must emphasize that, the unstripped ELF shared object sys.so shipped
> > by libjulia* is *NOT* a usual shared object which people are familiar
> > with. This shared object is called julia's "sysimage" which is compiled
> > from julia's base (core functionality) and standard library (written in
> > pure julia) to speed up julia interpreter initialization by reducing the
> > JIT overhead.  Julia is an interpreting language with heavy JIT
> > compilation... while we can even compile pure julia scripts into ELF
> > format... just like sys.so and [1]. To illustrate what sys.so is, here
> > is a random fragment of its symbol table[2]:
> > 
> >   3137: 000000000753d918     8 OBJECT  LOCAL  DEFAULT   23 +LinearAlgebra.Transpose8496
> >   3138: 0000000007544308     8 OBJECT  LOCAL  DEFAULT   23 +LinearAlgebra.UniformScaling14136
> >   3139: 0000000007536798     8 OBJECT  LOCAL  DEFAULT   23 +Logging.ConsoleLogger3352
> >   3140: 000000000754b690     8 OBJECT  LOCAL  DEFAULT   23 +Main.Base.##12#1321680
> >   3141: 0000000007540fe0     8 OBJECT  LOCAL  DEFAULT   23 +Main.Base.##223#22411153
> >   3142: 000000000753ef58     8 OBJECT  LOCAL  DEFAULT   23 +Main.Base.##223#2249585
> >   3143: 00000000075496a0     8 OBJECT  LOCAL  DEFAULT   23 +Main.Base.##227#22819234
> > 
> > Are they ordinary symbols that you are familiar with? They are more
> > likely sort of llvm cache in the native machine code format.
> > 
> > The consequence of stripping sys.so has already been stated by Graham.
> > It feels like Julia interpreter cannot trace (via backtrace/stacktrace)
> > into *script* after we did something tricky to the cache generated from
> > the original *script*. Such phenomenon, to my understanding, is
> > ridiculous to an interpreting language.
> > 
> > As a julia user and the de-facto julia package maintainer for more than
> > 10 recent uploads, I think making Debian's Julia interpreter behave
> > differently from upstream binary release at this point is not a good
> > idea, and the different behaviour is likely to confuse users in the
> > future.
> > 
> > Please consider giving Julia 1.X a chance to enter Buster, thanks.
> > 
> > [1] https://github.com/JuliaLang/PackageCompiler.jl
> > [2] readelf -sW sys.so
> > 
> > On Fri, Nov 23, 2018 at 04:42:53PM +0200, Graham Inggs wrote:
> > > Hi Bastian
> > > 
> > > On 2018/11/21 16:11, Bastian Blank wrote:
> > > > I have not seen a real explanation why it needs to be this and exactly
> > > > this way.  This setup was explained as either
> > > > - a workaround for a bug,
> > > > - a way to get stacktraces from users or
> > > > - a way to make autopkgtest run.
> > > 
> > > Stripping sys.so breaks one of Julia's language features, which is the
> > > ability to  trace into its standard library.  An example [1] is found in the
> > > documentation.
> > > 
> > > One of Julia's tests checks this, and hence autopkgtests fail if debug
> > > symbols are missing from sys.so, which is compiled from .jl scripts, not
> > > C/CXX source.
> > > 
> > > We could strip sys.so and create a manual debug symbols package, but in
> > > order to make the Debian package have the same features as upstream,  we
> > > would make the Julia package depend on it.
> > > 
> > > We would prefer to ship sys.so unstripped, but if you insist on having an
> > > extra binary package in the archive in order to silence Lintian, we will do
> > > it.
> > > 
> > > Regards
> > > Graham
> > > 
> > > [1] https://docs.julialang.org/en/v1.0.0/manual/stacktraces/